Mkv and pany

[nickhere]

Could the problem be in the duration time
that also not report properly for any files

[nickhere]

600 a1 same problem
cant read file
here the log

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

[nickhere]

BTW the volume control Works
my brother hates that because i keep playing with his tv

[Nadahar]

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 ).

[infidel]

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 .

[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?

[infidel]

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.

• A test to see if you fare any better if we omit metadata. If it helps, obv continue using it for the time being but remember to remove it if/when a fix transpires:

  update-ums-6.0.1-SNAPSHOT-avt-uri-bad-metadata.zip

  unzip to ums program folder

  (20.84 KiB) Downloaded 912 times

• A control test to see if the same error is thrown when we deliberately send different bad metadata:

  update-ums-6.0.1-SNAPSHOT-avt-uri-no-metadata.zip

  unzip to ums program folder

  (20.8 KiB) Downloaded 740 times

[infidel]

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.

[Nadahar]

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.

.. and this part of the discussion should move to issue #818 I think.

Agreed.

[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