UMS 10.6-10.8.2 Stuttering videos

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Startropic1
Posts: 21
Joined: Thu Jul 25, 2013 5:29 am

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by Startropic1 »

SubJunk wrote: Sun Aug 15, 2021 5:19 pm I think it's generally understood that media servers do these scans to keep up to date with the files. The main ones I'm aware of like Plex and Serviio do it too. Also there are big speed advantages to having the initial scan run for ALL users, because it pre-populates the cache. Without it, each folder needs to parse its contents in realtime, which for folders that have thousands of files can lead to timeouts on the renderer. It's one of the reasons we do this initial scan.

Anyway back to the problems, so Startropic1 are you saying that 10.5 works well for you but 10.6 onwards does not? I'm getting a bit lost in all the conversation
There was that one Suicide Squad video that still played a little glitchy, buuuut a couple updates:

I did test that video on my Xbox One (since it support 5GHz wifi) and it played perfectly on my Xbox. (The funny thing is the Xbox One is my preferred DVD/Bluray player/streaming device because the PS4 optical drive is cheap garbage, but I don't have the revised controllers that have the normal headphone jack. So if I want to use headphones I have to use my PS4.)

Also the logs are getting suuuuper big again and I just encoutered stuttering issues again with UMS 1.5.0 . I have been growing the test library but it is still miniscule compared to my actual media library. UMS froze/crashed while trying to save the latest log, so I had to manually zip it from the ProgramData folder.
There are 2 logs, the first log batch is from when I had the successful Xbox test. The second, later log is from when stuttering started happening again, (it was a 1080p 50 min long video, which for some reason was nearly 3GB in size. Needless to say bad encoding would not surprise me at all.)

Since they are so massive I had to make a mega folder: https://mega.nz/folder/KjAixRoT#U6KBcSOCFQNVGsr4DIMB0g

I'm going to upgrade back to 1.8.2 now and see how things go. I think we have enough data from 1.5.0 at this point.
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by mik_s »

Yeah those logs are massive. I tried to load them in my log viewer and my system ran out of memory and crashed. It's trial period had run out anyway so I will need to set it up again from scratch. :(

I'll see if I can split them into manageable chunks later to get an idea what is happening.

If I remember, Suicide Squad was in a supported format for the PS4 so it should have been streamed, so it won't need as much bandwidth then it would if it was being transcoded.
If it was a little glitchy then it may have been because the network spam from your TV was slowing it down or increasing I/O to your drives.
Did you make sure that your TV was disconnected from the network? as I think something its doing could be the cause.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Startropic1
Posts: 21
Joined: Thu Jul 25, 2013 5:29 am

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by Startropic1 »

mik_s wrote: Tue Aug 17, 2021 3:58 pm Yeah those logs are massive. I tried to load them in my log viewer and my system ran out of memory and crashed. It's trial period had run out anyway so I will need to set it up again from scratch. :(

I'll see if I can split them into manageable chunks later to get an idea what is happening.

If I remember, Suicide Squad was in a supported format for the PS4 so it should have been streamed, so it won't need as much bandwidth then it would if it was being transcoded.
If it was a little glitchy then it may have been because the network spam from your TV was slowing it down or increasing I/O to your drives.
Did you make sure that your TV was disconnected from the network? as I think something its doing could be the cause.
I did make sure my TV was disconnected last time I tested it on my PS4. Did not verify when I played it on my Xbox One.

The massive logs is probably another issue that should be addressed. Log lines are date/time stamps, so it wouldn't be that difficult to cap log file size and make UMS start writing a new log at some point while using those time stamps to get different file names for each log. You could even achieve this with the log.prev but adding a number every time that is being added to so you have separate files, log.prev1, log.prev2, etc.

I don't know if UMS is trying to read these massive logs during normal operation/logging, but that would be a problem if it is and splitting log files would alleviate this.
User avatar
SubJunk
Lead Developer
Posts: 3705
Joined: Sun May 27, 2012 4:12 pm

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by SubJunk »

I'll have a look at those logs later. I don't think UMS keeps the logs in memory so that should be ok but we'll know more when we look at those logs. Will have to wait for later for me as I'm set up to open big text files on another machine
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by mik_s »

Yeah there should be a cap on the size of the log file, and start a new one when it gets to that size. I have never seen one get this large though so there is definitely something seriously wrong.

OK. I started to look at ums150_dbg_2021-08-14-14-18 logs and the TV is definitely still on the network and looks like its interaction with UMS is stuck in a loop. I've only looked at the first 1/5th of the log (about 650 MB) and most of it is the following repeated constantly. (filtered to only show final verdict, there is a lot between each entry)

Code: Select all

Final verdict: "CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv" will be streamed since it is forced by configuration
Final verdict: "CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv" will be streamed since it is forced by configuration
Final verdict: "x-men_-_1x10_-_come_the_apocalypse_[vpc].avi" will be streamed since it is forced by configuration
Final verdict: "x-men_-_1x10_-_come_the_apocalypse_[vpc].avi" will be streamed since it is forced by configuration
Final verdict: "CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv" will be streamed since it is forced by configuration
Final verdict: "CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv" will be streamed since it is forced by configuration
Final verdict: "x-men_-_1x10_-_come_the_apocalypse_[vpc].avi" will be streamed since it is forced by configuration
The request made by the TV is

Code: Select all

Received a browse request from [TV][LG]47LA6200-UA [LG LA6200] (192.168.1.8:51770):

POST /upnp/control/content_directory HTTP/1.1

HEADER:
  SOAPAction: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"
  DLNADeviceName.lge.com: %5bTV%5d%5bLG%5d47LA6200-UA
  User-Agent: Linux/3.0.13 UPnP/1.0 LGE_DLNA_SDK/1.6.0 [TV][LG]47LA6200-UA/05.09.11 DLNADOC/1.50
  Connection: close
  Host: 192.168.1.2:5001
  Content-Length: 681
  Content-Type: text/xml; charset="utf-8"

CONTENT:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
      <ObjectID>120612</ObjectID>
      <BrowseFlag>BrowseDirectChildren</BrowseFlag>
      <Filter>res@resolution,res@nrAudioChannels,res@sampleFrequency,res@bitrate,dc:creator,res@dlna:cleartextSize,dc:date,upnp:genre,res,res@duration,res@size,upnp:albumArtURI,upnp:originalTrackNumber,upnp:album,upnp:artist,upnp:author</Filter>
      <StartingIndex>0</StartingIndex>
      <RequestedCount>100</RequestedCount>
      <SortCriteria/>
    </u:Browse>
  </s:Body>
</s:Envelope>
the data sent to the TV is

Code: Select all

The unescaped <Result> sent to [TV][LG]47LA6200-UA [LG LA6200] is:
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:pv="http://www.pv.com/pvns/" xmlns:sec="http://www.sec.co.kr/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/">
  <container childCount="1" id="120748" parentID="120612" restricted="1">
    <dc:title>Recommendations</dc:title>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_FLAGS=00900000000000000000000000000000">http://192.168.1.2:5001/get/120748/thumbnail0000JPEG_SM_Recommendations.jpg</res>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_FLAGS=00900000000000000000000000000000">http://192.168.1.2:5001/get/120748/thumbnail0000JPEG_TN_Recommendations.jpg</res>
    <upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_SM">http://192.168.1.2:5001/get/120748/thumbnail0000JPEG_SM_Recommendations.jpg</upnp:albumArtURI>
    <upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_TN">http://192.168.1.2:5001/get/120748/thumbnail0000JPEG_TN_Recommendations.jpg</upnp:albumArtURI>
    <upnp:class>object.container.storageFolder</upnp:class>
  </container>
  <container childCount="1" id="120749" parentID="120612" restricted="1">
    <dc:title>#--TRANSCODE--#</dc:title>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_FLAGS=00900000000000000000000000000000">http://192.168.1.2:5001/get/120749/thumbnail0000JPEG_SM_%23--TRANSCODE--%23.jpg</res>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_FLAGS=00900000000000000000000000000000">http://192.168.1.2:5001/get/120749/thumbnail0000JPEG_TN_%23--TRANSCODE--%23.jpg</res>
    <upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_SM">http://192.168.1.2:5001/get/120749/thumbnail0000JPEG_SM_%23--TRANSCODE--%23.jpg</upnp:albumArtURI>
    <upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_TN">http://192.168.1.2:5001/get/120749/thumbnail0000JPEG_TN_%23--TRANSCODE--%23.jpg</upnp:albumArtURI>
    <upnp:class>object.container.storageFolder</upnp:class>
  </container>
  <item id="120751" parentID="120612" restricted="1">
    <dc:title>x-men_-_1x10_-_come_the_apocalypse_[vpc]</dc:title>
    <upnp:episodeSeason>1</upnp:episodeSeason>
    <upnp:episodeNumber>10</upnp:episodeNumber>
    <upnp:seriesTitle>X-Men</upnp:seriesTitle>
    <upnp:programTitle>Come the Apocalypse</upnp:programTitle>
    <upnp:playbackCount>0</upnp:playbackCount>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" bitrate="123763" colorDepth="8" duration="0:19:41.808" framerate="25p" nrAudioChannels="2" protocolInfo="http-get:*:video/avi:DLNA.ORG_OP=01" resolution="432x324" sampleFrequency="48000" size="146264064">http://192.168.1.2:5001/get/120751/x-men_-_1x10_-_come_the_apocalypse_%5Bvpc%5D.avi</res>
    <desc id="2" nameSpace="http://ums/tags" type="ums-tags">
      <musicbrainztrackid>00000000-0000-0000-0000-000000000000</musicbrainztrackid>
      <musicbrainzreleaseid>00000000-0000-0000-0000-000000000000</musicbrainzreleaseid>
    </desc>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_FLAGS=00900000000000000000000000000000" resolution="300x225" size="14359">http://192.168.1.2:5001/get/120751/thumbnail0000JPEG_SM_x-men_-_1x10_-_come_the_apocalypse_%5Bvpc%5D.avi.jpg</res>
    <res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_CI=1;DLNA.ORG_FLAGS=00900000000000000000000000000000" resolution="160x120">http://192.168.1.2:5001/get/120751/thumbnail0000JPEG_TN_x-men_-_1x10_-_come_the_apocalypse_%5Bvpc%5D.avi.jpg</res>
    <upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_SM">http://192.168.1.2:5001/get/120751/thumbnail0000JPEG_SM_x-men_-_1x10_-_come_the_apocalypse_%5Bvpc%5D.avi.jpg</upnp:albumArtURI>
    <upnp:albumArtURI xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" dlna:profileID="JPEG_TN">http://192.168.1.2:5001/get/120751/thumbnail0000JPEG_TN_x-men_-_1x10_-_come_the_apocalypse_%5Bvpc%5D.avi.jpg</upnp:albumArtURI>
    <dc:date>2021-06-19T00:12:20</dc:date>
    <upnp:class>object.item.videoItem.movie</upnp:class>
  </item>
</DIDL-Lite>
I don't know anything about this communication but I noticed that the ID of that file is very large

Code: Select all

<container childCount="1" id="120749" parentID="120612" restricted="1">
As I understand it each file should only have 1 unique ID, if you only have 10 files then the max should be 10.
something is making the ID increase each time there is a request, and your TV thinks they are different files so keeps making requests.
Hopefully @Subjunk or @Nadahar can make sense of it

Near the beginning it was doing the same for the online content which I'd guess would impact your internet speed too.

as for network speeds

Code: Select all

Renderer Windows Media Player has an estimated network speed of 86.89845333333332 Mb/s
Renderer LG LA6200 has an estimated network speed of 16.582101980707893 Mb/s
Renderer PlayStation 4 has an estimated network speed of 8.341913184584177 Mb/s
Renderer Unknown renderer has an estimated network speed of 700.7744 Mb/s
Renderer Unknown renderer has an estimated network speed of 26.74284272376118 Mb/s
Renderer XBOXONE has an estimated network speed of 30.44228784631511 Mb/s
it is still very low for the TV and PS4. The xbox is better but probably not ideal, but would be enough to overcome to the network spam from the TV.
I don't know what the 2nd unknown renderer is yet, the other one is a loopback test I think and around 700 is normal.


I have some suggestions for your next test.
VERY IMPORTANT make sure your TV is off the network. If it is connected wired then remove the cable. If it is on wireless then go to its network connection options and delete the connection. when starting UMS your TV should not show up in the GUI, just your PS4 (and maybe windows media player) should appear. This should confirm that the TV is having a significant negative effect.

Disable the "enable external network" in the general settings tab. This will limit the available content that can be accessed to just your test library.

If you have not already done so, when you install the latest version select the clean install option to eliminate any other configuration problems.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by mik_s »

I skipped to the end of the log and it is exactly the same all the way though, and the final ID is massive.

Code: Select all

  <container childCount="1" id="562906" parentID="562801" restricted="1">
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by Nadahar »

I don't really have much to contribute here, you have left out some essential parts of the "response message" (you have just pasted the unescaped DIDL-lite message, but the "envelope" surrounding the escaped result is essential too - where information about the number of "matches" whether more matches than the ones in the response exist etc. If this is wrong, UMS is practically asking the TV to make the query again (supposedly with a different startindex, but it all depends on what UMS responds).

This isn't something I've seen before, so I supposed it's caused by a bug introduced after I left the project. There is definitely some bug in UMS here though, as you're saying each media entry should have just once ID (for the same renderer). The way UMS is written, different renderers will get different IDs for the same media item. Confusing as that is, it still shouldn't have an impact here and something else must be going on causing the ID to change.

I can make a couple of wild guesses, but they are just that.

One could be if the very buggy "dlnatreehack" option is enabled for the renderer. IMO there's never a good reason to use this option, as it makes UMS give responses that doesn't make sense to the renderer. Whoever came up with this hack, didn't really understand the browsing mechanism as far as I can tell.

Another possibility is that the memory leak "fix" that was made a while ago is really just a hack that will lead to inconsistencies, as I pointed out at the time. What it does is that it randomly delete cache entries from memory, hoping that the cache entry won't be deleted until it's done being useful. This was a "hack" made to avoid having to solve the real issue of cleaning up cache entries when they are no longer needed. Usually, if there is ample memory available, Java is quite "lazy" when it comes to delete "weak" references (which is what is used in the hack). A "weak" reference basically means that Java is free to delete it whenever it feels like it, it's usually used when other objects hold a "non-weak" reference that will prevent objects from being recycled for pieces of code that just need to "monitor" objects but not impact their lifecycle. That's not they way it's being used in this hack, here the weak reference is the "primary" reference, and thus Java's garbage collector can recycle them at any time. If memory is scarce, either because little memory is available, or because lots have been consumed for other reasons, Java will become much more aggressive in recycling objects. It is possible to imagine a situation where Java ends up recycling the cached resource object between two requests from the TV, which would cause a new resource with a new ID to be generated upon the next request. It would explain why ID's would increase, and the only way to prevent this is to remove the "hack" that lets cached resources be recycled at random.
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by mik_s »

The other logs are very similar with a couple of files constantly repeating. I don't see anything else interesting and my computer is struggling so I think I will end it there.


@Nadahar sorry I don't know what I'm doing :lol:
This a similar response from the other log

Code: Select all

TRACE 2021-08-16 18:32:21.094 [HTTPv2 Request Worker 8] Response sent to [TV][LG]47LA6200-UA [LG LA6200]:

HEADER:
  HTTP/1.1 200 OK
  Content-Type: text/xml; charset="utf-8"
  Server: Windows_10-amd64-10.0, UPnP/1.0 DLNADOC/1.50, UMS/10.5.0
  Content-Length: 5415

CONTENT:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <u:BrowseResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
            <Result>&lt;DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:sec="http://www.sec.co.kr/" xmlns:pv="http://www.pv.com/pvns/"&gt;&lt;container id="122188" childCount="1" parentID="119642" restricted="1"&gt;&lt;dc:title&gt;Recommendations&lt;/dc:title&gt;&lt;res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_FLAGS=00900000000000000000000000000000"&gt;http://192.168.1.2:5001/get/122188/thumbnail0000JPEG_SM_Recommendations.jpg&lt;/res&gt;&lt;res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_FLAGS=00900000000000000000000000000000"&gt;http://192.168.1.2:5001/get/122188/thumbnail0000JPEG_TN_Recommendations.jpg&lt;/res&gt;&lt;upnp:albumArtURI dlna:profileID="JPEG_SM" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;http://192.168.1.2:5001/get/122188/thumbnail0000JPEG_SM_Recommendations.jpg&lt;/upnp:albumArtURI&gt;&lt;upnp:albumArtURI dlna:profileID="JPEG_TN" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;http://192.168.1.2:5001/get/122188/thumbnail0000JPEG_TN_Recommendations.jpg&lt;/upnp:albumArtURI&gt;&lt;upnp:class&gt;object.container.storageFolder&lt;/upnp:class&gt;&lt;/container&gt;&lt;container id="122189" childCount="1" parentID="119642" restricted="1"&gt;&lt;dc:title&gt;#--TRANSCODE--#&lt;/dc:title&gt;&lt;res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_FLAGS=00900000000000000000000000000000"&gt;http://192.168.1.2:5001/get/122189/thumbnail0000JPEG_SM_%23--TRANSCODE--%23.jpg&lt;/res&gt;&lt;res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_FLAGS=00900000000000000000000000000000"&gt;http://192.168.1.2:5001/get/122189/thumbnail0000JPEG_TN_%23--TRANSCODE--%23.jpg&lt;/res&gt;&lt;upnp:albumArtURI dlna:profileID="JPEG_SM" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;http://192.168.1.2:5001/get/122189/thumbnail0000JPEG_SM_%23--TRANSCODE--%23.jpg&lt;/upnp:albumArtURI&gt;&lt;upnp:albumArtURI dlna:profileID="JPEG_TN" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;http://192.168.1.2:5001/get/122189/thumbnail0000JPEG_TN_%23--TRANSCODE--%23.jpg&lt;/upnp:albumArtURI&gt;&lt;upnp:class&gt;object.container.storageFolder&lt;/upnp:class&gt;&lt;/container&gt;&lt;item id="122191" parentID="119642" restricted="1"&gt;&lt;dc:title&gt;CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR&lt;/dc:title&gt;&lt;upnp:episodeSeason&gt;1&lt;/upnp:episodeSeason&gt;&lt;upnp:episodeNumber&gt;22&lt;/upnp:episodeNumber&gt;&lt;upnp:seriesTitle&gt;CSI: Miami&lt;/upnp:seriesTitle&gt;&lt;upnp:programTitle&gt;Tinder Box&lt;/upnp:programTitle&gt;&lt;upnp:playbackCount&gt;1&lt;/upnp:playbackCount&gt;&lt;upnp:lastPlaybackTime&gt;2021-08-13 18:51:36.993&lt;/upnp:lastPlaybackTime&gt;&lt;upnp:lastPlaybackPosition&gt;0:43:14.000&lt;/upnp:lastPlaybackPosition&gt;&lt;res xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:video/x-matroska:DLNA.ORG_PN=AVC_MKV_MP_HD_AC3;DLNA.ORG_OP=01" size="1423319888" duration="0:43:00.384" resolution="1280x720" framerate="24p" bitrate="551592" nrAudioChannels="6" sampleFrequency="48000" colorDepth="8"&gt;http://192.168.1.2:5001/get/122191/CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv&lt;/res&gt;&lt;desc id="2" nameSpace="http://ums/tags" type="ums-tags"&gt;&lt;musicbrainztrackid&gt;00000000-0000-0000-0000-000000000000&lt;/musicbrainztrackid&gt;&lt;musicbrainzreleaseid&gt;00000000-0000-0000-0000-000000000000&lt;/musicbrainzreleaseid&gt;&lt;/desc&gt;&lt;res size="2861" resolution="300x225" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_FLAGS=00900000000000000000000000000000"&gt;http://192.168.1.2:5001/get/122191/thumbnail0000JPEG_SM_CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv.jpg&lt;/res&gt;&lt;res resolution="160x120" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_CI=1;DLNA.ORG_FLAGS=00900000000000000000000000000000"&gt;http://192.168.1.2:5001/get/122191/thumbnail0000JPEG_TN_CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv.jpg&lt;/res&gt;&lt;upnp:albumArtURI dlna:profileID="JPEG_SM" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;http://192.168.1.2:5001/get/122191/thumbnail0000JPEG_SM_CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv.jpg&lt;/upnp:albumArtURI&gt;&lt;upnp:albumArtURI dlna:profileID="JPEG_TN" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"&gt;http://192.168.1.2:5001/get/122191/thumbnail0000JPEG_TN_CSI.Miami.S01E22.Tinder.Box.720p.WEB-DL.DD5.1.H.264-DNR.mkv.jpg&lt;/upnp:albumArtURI&gt;&lt;dc:date&gt;2021-08-13T16:57:20&lt;/dc:date&gt;&lt;upnp:class&gt;object.item.videoItem.movie&lt;/upnp:class&gt;&lt;/item&gt;&lt;/DIDL-Lite&gt;</Result>
            <NumberReturned>3</NumberReturned>
            <TotalMatches>3</TotalMatches>
            <UpdateID>2</UpdateID>
        </u:BrowseResponse>
    </s:Body>
</s:Envelope>
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by Nadahar »

@mik_s The "clue" is to compare the specific request with the specific response. In the other example the request was for 100 items as far as I can remember, and this answer claims to return 3 items and that there are 3 in total (in the "folder" in question). That looks fine, assuming that the DIDL-Lite actually contains 3 items of course.

The "dlnatreehack" setting makes this be completely inconsistent, like for example returning more items than what it claims the total is, or even responding with a total of zero. Nonsensical answers like that will ofte cause renderers to simply repeat the request... until it eventually "give up" because of some limitation in the renderer code like a "max retry count". If a renderer doesn't have such "max retry" logic, it could in theory repeat the request indefinitely. It doesn't look like that's the case here though, which makes me suspect that the memory hack is the underlying problem.
Startropic1
Posts: 21
Joined: Thu Jul 25, 2013 5:29 am

Re: UMS 10.6-10.8.2 Suuuuuuuuuuper Unstable

Post by Startropic1 »

mik_s wrote: Wed Aug 18, 2021 7:22 am I have some suggestions for your next test.
VERY IMPORTANT make sure your TV is off the network. If it is connected wired then remove the cable. If it is on wireless then go to its network connection options and delete the connection. when starting UMS your TV should not show up in the GUI, just your PS4 (and maybe windows media player) should appear. This should confirm that the TV is having a significant negative effect.

Disable the "enable external network" in the general settings tab. This will limit the available content that can be accessed to just your test library.

If you have not already done so, when you install the latest version select the clean install option to eliminate any other configuration problems.
I did indeed do a clean install of 1.8.2, I might also go ahead and delete the old bloated logs from their UMS folder, (at least as a temporary fix for that bit)

As for my TV, I wager it reconnected itself. The mechanism in its GUI for handling network connections is very NOT intuitive, most notably that there is NO direct way to disable a connection. There is no list of my connections from where I can just delete the thing. (Very stupid, I will try to do a firmware update of my TV.) I can always go to the nuclear option and edit the .conf for my TV in UMS and make it do nothing.

I definitely did manage to get the TV disconnected during one test, (and I tested to make sure before doing anything with UMS that time), but it does not surprise me that it managed to reconnect.
Post Reply