Page 4 of 6

Re: Mkv and pany

Posted: Tue Feb 02, 2016 3:15 pm
by nickhere
Could the problem be in the duration time
that also not report properly for any files

Re: Mkv and pany

Posted: Tue Feb 02, 2016 3:32 pm
by nickhere
600 a1 same problem
cant read file
here the log

This program really a pain to debug
lots of steps to take

Re: Mkv and pany

Posted: Tue Feb 02, 2016 3:37 pm
by nickhere
BTW the volume control Works
my brother hates that because i keep playing with his tv

Re: Mkv and pany

Posted: Tue Feb 02, 2016 3:39 pm
by Nadahar
infidel wrote:The code link was meant more for Nadahar, who was also part of the discussion back then :).
I still am thank you, but I've learned to keep my mouth shut when I have nothing to contribute (or at least I'm practicing :geek: ).

Re: Mkv and pany

Posted: Tue Feb 02, 2016 3:55 pm
by infidel
nickhere wrote:600 a1 same problem
Darn, but it could still be an xml parsing issue, since it's hard to believe it's actually rejecting mkv and mp4 mimetypes. The fact that volume control works (too well, maybe :-)) also points to maybe malformed metadata. Will post more if I find anything, maybe Nadahar can spot something in the xml too :).

Re: Mkv and pany

Posted: Tue Feb 02, 2016 5:08 pm
by Nadahar
@infidel This is (one of) the XML's being sent as far as I can see:

Code: Select all

<item id="54$Temp" parentID="Temp" restricted="true">
	<dc:title>Angie.Tribeca.S01E03.1080p.HDTV.x264-SERIOUSLY</dc:title>
	<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:video/x-matroska:DLNA.ORG_OP=01" size="953967515" duration="00:19:55.00" resolution="1920x1080" bitrate="798251" nrAudioChannels="2" sampleFrequency="48000">http://192.168.0.114:5001/get/54$Temp/Angie.Tribeca.S01E03.1080p.HDTV.x264-SERIOUSLY.mkv</res>
	<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:video/x-matroska:DLNA.ORG_OP=01" size="953967515" duration="00:19:55.00" resolution="1920x1080" bitrate="798251" nrAudioChannels="2" sampleFrequency="48000">http://192.168.0.114:5001/get/54$Temp/Angie.Tribeca.S01E03.1080p.HDTV.x264-SERIOUSLY.mkv</res>
	<res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:video/x-matroska:DLNA.ORG_OP=01" size="953967515" duration="00:19:55.00" resolution="1920x1080" bitrate="798251" nrAudioChannels="2" sampleFrequency="48000">http://192.168.0.114:5001/get/54$Temp/Angie.Tribeca.S01E03.1080p.HDTV.x264-SERIOUSLY.mkv</res>
	<upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_TN">http://192.168.0.114:5001/get/54$Temp/thumbnail0000Angie.Tribeca.S01E03.1080p.HDTV.x264-SERIOUSLY.mkv</upnp:albumArtURI>
	<upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_SM">http://192.168.0.114:5001/get/54$Temp/thumbnail0000Angie.Tribeca.S01E03.1080p.HDTV.x264-SERIOUSLY.mkv</upnp:albumArtURI>
	<upnp:class>object.item.videoItem</upnp:class>
</item>
While I don't see anything wrong when it comes to opening and closing, escaping etc, I see several things with the XML itself - but no worse than what we already send to the renderers. I'm very interested in why we send 3 (from what I can see) completely identical res objects, and then go on to send album art (which according to the specification is only allowed for object.item.audioItem or object.container.album.musicAlbum and descendants) for a videoItem. On top of that, we specify the same URL for JPEG_TN and JPEG_SM which is by definition wrong since JPEG_TN is defined to be exactly 180x180 and JPEG_SM to 360x360. But all this is as we do it standard, I can't really see any degradation from your unEncodeXML method.

I don't know if the renderer is more picky when sent from a control point, but that would be strange. Also, the error is illegal MIME type which is a bit strange. We're supposed to send a profileID as well, and for video/x-matroska the following is valid: AVC_MKV_MP_ HD_AAC_MULT5, AVC_MKV_MP_ HD_HEAAC_L4, AVC_MKV_MP_ HD_AC3, AVC_MKV_MP_ HD_MPEG1_L3, AVC_MKV_HP_ HD_AAC_MULT5, AVC_MKV_HP_ HD_HEAAC_L4, AVC_MKV_HP_ HD_AC3, AVC_MKV_HP_ HD_MPEG1_L3, AVC_MKV_MP_HD_DTS, AVC_MKV_MP_HD_DTSE, AVC_MKV_MP_HD_DTSL, AVC_MKV_MP_HD_EAC3, AVC_MKV_HP_HD_DTS, AVC_MKV_HP_HD_DTSE, AVC_MKV_HP_HD_DTSL, AVC_MKV_HP_HD_EAC3, AVC_MKV_HP_HD_MLP. Since we omit the profileID, I guess it has every right to claim invalid MIME type - but again, it's very strange if this is only demanded when sent this way. It isn't that stupid that the file in question is transcoded when played "normally" but is sent as if being streamed this way?

Re: Mkv and pany

Posted: Wed Feb 03, 2016 1:32 am
by infidel
nickhere wrote:600 a1 same problem
A couple of tests to try. To run them put the enclosed update.jar next to ums.jar in your UMS program folder and restart UMS, and remove it when done.

Re: Mkv and pany

Posted: Wed Feb 03, 2016 1:42 am
by infidel
Nadahar wrote:I see several things with the XML itself...
All good points/questions, I think you're our resident expert on the DLNA spec now :). Depending on nickhere's test results maybe we can try testing with more spec-compliant metadata, and look into the apparent transcode/stream contradiction, and this part of the discussion should move to issue #818 I think.

Re: Mkv and pany

Posted: Wed Feb 03, 2016 2:10 am
by Nadahar
infidel wrote:I think you're our resident expert on the DLNA spec now :)
Scary, I've only browsed DLNA 2014 guidlines part 1 and 2 looking for thumbnail related information.
infidel wrote:.. and this part of the discussion should move to issue #818 I think.
Agreed.

Re: Mkv and pany

Posted: Wed Feb 03, 2016 7:04 am
by nickhere
It work with nometa-data but
you need to send the stop command and a clear buffer

The bad metadata one i couldnt even contact the tv
but the mp4 played on the status screen

the procedure i used for each

turn tv on (this made sure the buffer was clear)
run ums
play both create debug log

There is a buffering problem. some times i try to switch
and the mkv wouln't work.
had to shut down everything