[PROBLEM] IPv6[RFC 3986] URI format issue for display some information

[storaid]

Hello,
I'm testing Moode as a UPnP Renderer using IPv6.
When a controller (TuneBrowser v5.7.0) sends a playback request via a standard IPv6-based ProxyStream URI, for example:
http://[2001:b030:7020:1:948d:6d32:3bdf:ooxx]:29400/TuneID/00034067-xxxxx.flac

The on-screen some metadata is not rendered properly or completely missing.
   
   
This URI format is valid per [RFC 3986]

Please confirm this, thank you!

[Tim Curtis]

What's needed to reproduce the issue?

[storaid]

What's needed to reproduce the issue?

It's simple!
try this CAS player TuneBrowser v5.7.0
https://tunebrowser.tikisoft.net/download/
Set the IPv6 level as "Active" and re-launch it
   

Thanks

[Tim Curtis]

lol, "It's simple!" ;-)

Couple things:

1. Its a Windows-only player, Japanese support Forum
2. Its not open source
3. The screen shot suggests files are accessed via an IPv6 Internet proxy which means the files are remote and don't reside on your local network.

moOde only supports accessing local files but I think I know at least one of the code blocks thats blowing up.

See file /var/www/inc/mpd.php starting at line 783

Code:

        // Determine badging
        // NOTE: This is modeled after the code in getEncodedAt()
        if (!(substr($song['file'], 0, 4) == 'http' && !isset($current['duration']))) { // Not a radio station
           if (substr($song['file'], 0, 4) == 'http') { // UPnP file
               // [0] bits, [1] rate, [2] channels [3] ext, [4] duration
               $result = sysCmd('mediainfo --Inform="Audio;file:///var/www/util/mediainfo.tpl" ' . '"' . $song['file'] . '"');
               $format[0] = $result[1]; // rate
               $format[1] = $result[0]; // bits
               $format[2] = $result[2]; // channels
           } else { // Song file
               sendMpdCmd($sock, 'lsinfo "' . $song['file'] . '"');
               $songData = parseDelimFile(readMpdResp($sock), ': ');
               // [0] rate, [1] bits, [2] channels
               $format = explode(':', $songData['Format']);
           }

Try the command below and you will get an error.

Code:

mediainfo "http://[2001:b030:7020:1:948d:6d32:3bdf:ooxx]:29400/TuneID/00034067-xxxxx.flac"

You best bet is to either switch off the "experimental" IPv6 proxy and try using IPv4 or modify the moOde code to avoid trying to get metadata via mediainfo from the remote UPnP file.

[storaid]

lol, "It's simple!" ;-)

Couple things:

1. Its a Windows-only player, Japanese support Forum
2. Its not open source
3. The screen shot suggests files are accessed via an IPv6 Internet proxy which means the files are remote and don't reside on your local network.

moOde only supports accessing local files but I think I know at least one of the code blocks thats blowing up.

See file /var/www/inc/mpd.php starting at line 783

Code:

        // Determine badging
        // NOTE: This is modeled after the code in getEncodedAt()
        if (!(substr($song['file'], 0, 4) == 'http' && !isset($current['duration']))) { // Not a radio station
           if (substr($song['file'], 0, 4) == 'http') { // UPnP file
               // [0] bits, [1] rate, [2] channels [3] ext, [4] duration
               $result = sysCmd('mediainfo --Inform="Audio;file:///var/www/util/mediainfo.tpl" ' . '"' . $song['file'] . '"');
               $format[0] = $result[1]; // rate
               $format[1] = $result[0]; // bits
               $format[2] = $result[2]; // channels
           } else { // Song file
               sendMpdCmd($sock, 'lsinfo "' . $song['file'] . '"');
               $songData = parseDelimFile(readMpdResp($sock), ': ');
               // [0] rate, [1] bits, [2] channels
               $format = explode(':', $songData['Format']);
           }

Try the command below and you will get an error.

Code:

mediainfo "http://[2001:b030:7020:1:948d:6d32:3bdf:ooxx]:29400/TuneID/00034067-xxxxx.flac"

You best bet is to either switch off the "experimental" IPv6 proxy and try using IPv4 or modify the moOde code to avoid trying to get metadata via mediainfo from the remote UPnP file.

Thank you for the detailed explanation and pointing out the code.
The issue seems to be that mediainfo (or the underlying shell) does not properly handle [IPv6]:port in HTTP URLs.(RFC 3986)

[Tim Curtis]

lol, "It's simple!" ;-)

Couple things:

1. Its a Windows-only player, Japanese support Forum
2. Its not open source
3. The screen shot suggests files are accessed via an IPv6 Internet proxy which means the files are remote and don't reside on your local network.

moOde only supports accessing local files but I think I know at least one of the code blocks thats blowing up.

See file /var/www/inc/mpd.php starting at line 783

Code:

        // Determine badging
        // NOTE: This is modeled after the code in getEncodedAt()
        if (!(substr($song['file'], 0, 4) == 'http' && !isset($current['duration']))) { // Not a radio station
           if (substr($song['file'], 0, 4) == 'http') { // UPnP file
               // [0] bits, [1] rate, [2] channels [3] ext, [4] duration
               $result = sysCmd('mediainfo --Inform="Audio;file:///var/www/util/mediainfo.tpl" ' . '"' . $song['file'] . '"');
               $format[0] = $result[1]; // rate
               $format[1] = $result[0]; // bits
               $format[2] = $result[2]; // channels
           } else { // Song file
               sendMpdCmd($sock, 'lsinfo "' . $song['file'] . '"');
               $songData = parseDelimFile(readMpdResp($sock), ': ');
               // [0] rate, [1] bits, [2] channels
               $format = explode(':', $songData['Format']);
           }

Try the command below and you will get an error.

Code:

mediainfo "http://[2001:b030:7020:1:948d:6d32:3bdf:ooxx]:29400/TuneID/00034067-xxxxx.flac"

You best bet is to either switch off the "experimental" IPv6 proxy and try using IPv4 or modify the moOde code to avoid trying to get metadata via mediainfo from the remote UPnP file.

Thank you for the detailed explanation and pointing out the code.
The issue seems to be that mediainfo (or the underlying shell) does not properly handle [IPv6]:port in HTTP URLs.(RFC 3986)

It might be worth submitting an issue to the medainfo repo.
https://github.com/MediaArea/MediaInfo/issues

[TheOldPresbyope]

Let's try to narrow the search for the guilty.

When I enter "URL using bad/illegal format or missing URL" into my favorite search engine, I see a string of hits, all of which are curl-related.

Hmm. 

A little work with apt-cache reveals that the mediainfo package depends on the libmediainfo0v5 package which depends on the libcurl3-gnutls package. 

Searching this time on "mediainfo curl" I find that mediainfo uses curl to download just enough of a remote file to extract needed data.

So, let's try a simpler test case which doesn't require a UPnP environment.

My network is dual IPv4/IPv6 out to the world and all my LAN-connected devices have IPv4 and IPv6 interfaces enabled.


One of my moOde players has the IPv6 link-local address fe80::c07a:3148:365d:c61d

From a second moOde player

Code:

rho@sunroom:~ $ wget -o test 'http://[fe80::c07a:3148:365d:c61d]:/mnt/SDCARD/Stereo Test/LRMonoPhas64.flac'
rho@sunroom:~ $ ls
piano.sh  test

Ok, wget succeeds.

Code:

rho@sunroom:~ $ curl -o test1 'http://[fe80::c07a:3148:365d:c61d]:/mnt/SDCARD/Stereo Test/LRMonoPhas64.flac'
curl: (3) URL using bad/illegal format or missing URL

Nope, curl fails.

I agree with Tim that posting to the mediainfo forum is the right thing to do.




Regards,
Kent

[the_bertrum]

Or stop using an experimental feature on that tunebrowser thing. It is marked as experimental for a reason.

[storaid]

Hello all,
I've submitted the issue to MediaInfo repo.:
https://github.com/MediaArea/MediaInfo/issues/1067

[storaid]

Or stop using an experimental feature on that tunebrowser thing.  It is marked as experimental for a reason.

Yeah,
That's true — the IPv6 option in TuneBrowser is currently marked as experimental.
According to Tiki san (the developer), this is mainly due to the complexity of the SSDP discovery process. 

In v5.7.0, he's making efforts to evaluate IPv6 behavior.
The challenge is that UPnP device selection is based on the friendly name, but the initial protocol (SSDP) uses the USN to decide between IPv4 and IPv6.

Since many devices change their USN or IP dynamically, it's difficult for the player to remember which protocol to prefer for each device.
So at this stage, the IPv6 feature is being tested cautiously.
This option is global.