Universal Media Server | Forum

Same results for seeking backward.

I wonder if some of these issues have anything to do with the fact that the TV is recognized as two different renderers:

A: LG Smart TV 49NANO866NA with the service webos-second-screen-3000-3001
B: LG TV 1.0 LG WebOSTV DMRplus with the services AVTransport, ConnectionManager, RenderingControl

According to the UMS UI, sometimes playback is going through one, sometimes the other. B has some controls on the UMS UI (which don't work) and when in use sometimes (unclear when; not always) displays the name of the video that is playing underneath it. An attempt to use the controls on B when A was the active one seems to have forced UMS to change from A to B immediately(?) Some more results:

- Neither of them can seek.
- Using B, I have succeeded once in resuming from the transcode menu to the point where the video was after an interruption (server restart I think). It was the only time that option was presented so far.
- Using B, I seem to be able to pause and resume. Tested with a pause length of ~1.5 minutes. (EDIT: However, I have previously failed to resume after a long pause, which kicked me out of DLNA entirely - didn't see which renderer was being used at the time. Maybe A?)
- Even if seeking doesn't completely restart the video, it can have odd results like looping the same small portion of the video.

Since right now UMS is assuming B I can't run more tests on A but I will as soon as it switches again.

Exceptions are liberally peppered throughout the debug log during these tests. If you want me to perform any specific sequence of steps and produce a trace log please let me know.

EDIT: In response to Nadahar's post just now: Anything I can do to help figure out why seek doesn't work?

The switching of renderers seems like a likely cause for confusion. Other than that, somebody would have to go through the log in detail and see exactly what happens. I think this is a case for the devs.

I can see in the logs:
and I can see that the maximum bitrate is set to 0. I would recommend setting it to 90 even on wired, because when transcoding to MPEG-2 (as is happening here) it can spike to ridiculous bitrates if we allow it to.

One thing to try to fix stuttering with MEncoder would be to add to your renderer config.

I can see your TV is identifying itself as , is the "NANO866NA" part of that something you added, or is that default for that TV? If it is default then we can try to improve the detection and settings by making a new config for your TV.

One thing to try with seeking is to remove from the renderer config.

You overestimate me, SubJunk This is indeed the LG 49NANO866NA:

https://www.lg.com/uk/tvs/lg-49nano866na

The identification string is the native default.

I will try all the things you suggest in a minute and share the results. One thing I noticed during previous tests was that stuff I put in the renderer config didn't seem to be used (for example ffmpeg flags weren't reflected in the ffmpeg command line logged in the debug log) but maybe I was using the wrong renderer. I'll let you know.

I think I successfully disabled SeekByTime. Or at least I added SeekByTime = false to both renderer custom configs and fully quit and restarted the program, so hopefully that's enough. I don't see seekbytime in debug.log .

After disabling it, unfortunately, seek still doesn't work in ffmpeg mode (same outcomes as before).

During this session UMS has been detecting the TV as Renderer A, so I used the opportunity to test pause and resume. I can confirm that pause and resume work for A too, so I'm not sure why it failed that other time. Maybe there's a large minimum delay after which paused transcodes will fail?

MPEGTS-H264-AC3 does successfully get rid of stuttering with mencoder. In ffmpeg, it seems to add some very brief glitches (flashing artifacts), but no stuttering either.

During this session, the TV reports that the seek function isn't available (so I can't even try to seek). It's using renderer B.

Using MPEG2 with MaxVideoBitrateMbps set to 90, and SeekByTime set to False again:

- All options changes are explicitly logged in the debug.log, so I know they loaded properly
- ffmpeg still runs fine
- mencoder still stutters, unfortunately
- Seeking is available again but still broken on all tests on both modes

EDIT: SeekByTime = exclusive doesn't help either...

Since even without stuttering mencoder doesn't seek, and even while the bitrate is restricted it stutters, I removed all the attempted changes and ran the following test:

- Restarted in trace mode
- Opened the same video I have been using today using ffmpeg transcoding (UMS selected renderer A)
- Waited a bit then attempted to seek, three successive times. Seeking didn't work (of course). Final outcome was looping in the same portion of the video.

The log is attached; hopefully this will be of use in figuring out why seeking is broken (that's the only real issue here).

At this point I'd also appreciate learning about the following two things, if possible:
- A setting I can use to get mencoder to not stutter without having to change the video profile or bitrate for ffmpeg (since the default seems to yield the best quality and no other issues)
- A way to force the default action for every video to be transcoding with ffmpeg instead of streaming (I seem to recall this existing in a past version?)

Thanks!

I can't answer the MEncoder "non-stutter" setting, but I'd say that defaulting to transcode with FFmpeg probably isn't what you want. Streaming, when the renderer can handle the format natively, is the superior option. It yields the best quality and it makes seeking fast and effortless. Sadly, it's often not viable, either because of format/codec incompatibility or because of subtitles, which is where transcoding comes in.

You can control this behavior by modifying the "Supported" lines in your renderer configuration. It's as simple as any media that matches a "Supported" line will be streamed, while those with no match will be transcoded. So, if you'd want everything to be transcoded, all you'd have to do is to remove all "Supported" lines. But, believe me, this ISN'T what you want.

Yeah like Nadahar said it's good to set up a good renderer config so that streaming always happens when it can. LG TVs have pretty good file support. I will make one for you to try.

Unfortunately, some devices just don't seem to be able to seek while transcoding, or at least we haven't been able to figure out how yet. We have some hacks that sometimes work. The next one to try is adding to the renderer config.
I can see that some LG TV configs have also used so that is another one to try.

You might find the quality problems improve by specifying a preset with FFmpeg too. For my TV I use