Trying to find a proper workaround for seeking in a transcoded stream
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Re: Trying to find a proper workaround for seeking in a transcoded stream
That config is for the Philips-Android so won't have any effect on my Samsung 
I just think it is because it's media player is crap and not able to seek while playing over the network. Not sure if later models suffer from the same issues.
I just think it is because it's media player is crap and not able to seek while playing over the network. Not sure if later models suffer from the same issues.
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.
Re: Trying to find a proper workaround for seeking in a transcoded stream
My old phone died on me and had to buy a new one, a Samsung A21s.
(cheapest one available but will be paying for it for 2 years
exactly £6.66 a month, that might be a sign 
)
I have been playing around with it to get used to the new OS (old one was still on lollipop) and tried out the media players streaming to my TV.
I found out it was possible to skip to any time using the time bar in the app on the phone even when the controls were greyed out on the TV.
So it is possible for it to seek over the network.
It was then when I remembered there is a search time bar on the TV, it's just normally hidden in a menu so I forgot about it.
Trying it with UMS works just fine for streamed video.
Unfortunately it don't work for transcoded videos, that option is missing
I tried all the combinations for transcoding settings and the only thing that changes it is "SeekByTime = exclusive" which will show a total time of 307:29:29 instead of 00:00:01 for any video, but still no search by time.
(cheapest one available but will be paying for it for 2 years
exactly £6.66 a month, that might be a sign )I have been playing around with it to get used to the new OS (old one was still on lollipop) and tried out the media players streaming to my TV.
I found out it was possible to skip to any time using the time bar in the app on the phone even when the controls were greyed out on the TV.
So it is possible for it to seek over the network.
It was then when I remembered there is a search time bar on the TV, it's just normally hidden in a menu so I forgot about it.
Trying it with UMS works just fine for streamed video.
- Search Time Bar.jpg (273.74 KiB) Viewed 3777 times
I tried all the combinations for transcoding settings and the only thing that changes it is "SeekByTime = exclusive" which will show a total time of 307:29:29 instead of 00:00:01 for any video, but still no search by time.
- No Search Time Bar.jpg (286.74 KiB) Viewed 3777 times
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.
Re: Trying to find a proper workaround for seeking in a transcoded stream
Two things must be in place for seeking to work when transcoding:
1) UMS must inform the renderer that time-based seeking is available in a consistent manner, and it must provide a (correct) total time.
2) The renderer must support time-based seeking.
It tried to see if I could find some device that implements DLNA that has been on the marked for a while so that I might be able to pick one up for cheap (excluding things like TVs). To my disappointment, I didn't manage to find a device that qualifed. Having such a device would be very helpful. The PS3 does support time-based seeking, but it's made to the very first version of DLNA (1.0), which lacks a lot compared to DLNA 1.5 which most renderers implements. In addition, the PS3 isn't actually a renderer (DMR), it's merely a "DLNA player" (DMP), which means that it only implements the bare minimum. Anyway, during my search for such a device, I looked through a lot of "DLNA certificates" which can be found on the DLNA website. What I found was that the vast majority of the certificates I looked up did NOT implement time-based seeking, so assuming that I wasn't just unlucky with the ones I (randomly) picked, it doesn't seem that support for time-based seeking is that wide-spread.
It's a shame, because it really ruins transcoding. But, seen with the eyes of the commercial manufacturers, I guess it's not really important. They mostly seem to implement DLNA so that their devices can exchange media with each other - and they will usually stick to some format/codec combination that is supported across their products, so that transcoding isn't an issue. It also seems like there's many assumptions both in standards and other places that sources where byte-seek isn't available means "live" sources like broadcasts. From that point of view, it's easy to see why seeking in such sources isn't a priority.
So, while both 1) and 2) can cause this to fail, I suspect that 2) often is the cause.
1) UMS must inform the renderer that time-based seeking is available in a consistent manner, and it must provide a (correct) total time.
2) The renderer must support time-based seeking.
It tried to see if I could find some device that implements DLNA that has been on the marked for a while so that I might be able to pick one up for cheap (excluding things like TVs). To my disappointment, I didn't manage to find a device that qualifed. Having such a device would be very helpful. The PS3 does support time-based seeking, but it's made to the very first version of DLNA (1.0), which lacks a lot compared to DLNA 1.5 which most renderers implements. In addition, the PS3 isn't actually a renderer (DMR), it's merely a "DLNA player" (DMP), which means that it only implements the bare minimum. Anyway, during my search for such a device, I looked through a lot of "DLNA certificates" which can be found on the DLNA website. What I found was that the vast majority of the certificates I looked up did NOT implement time-based seeking, so assuming that I wasn't just unlucky with the ones I (randomly) picked, it doesn't seem that support for time-based seeking is that wide-spread.
It's a shame, because it really ruins transcoding. But, seen with the eyes of the commercial manufacturers, I guess it's not really important. They mostly seem to implement DLNA so that their devices can exchange media with each other - and they will usually stick to some format/codec combination that is supported across their products, so that transcoding isn't an issue. It also seems like there's many assumptions both in standards and other places that sources where byte-seek isn't available means "live" sources like broadcasts. From that point of view, it's easy to see why seeking in such sources isn't a priority.
So, while both 1) and 2) can cause this to fail, I suspect that 2) often is the cause.