Could not resume in-progress recordings

[MBSki 1009]

7 minutes ago, softworkz said:

Oh - no, not at all. Transcoding should only be done when absolutely necessary.

Ok, no problem. Understand....kinda. It's the only way I've been able to skip within in-progress recordings though. Is that just because I was watching a ts file that isn't currently direct play supported? It was a 1080i recording and those are the ones I often have issues with even when it's a completed recording.

[SamES 890]

We always see this issue on Samsung and LG TV's as well.

DirectPlay on in-progress recordings don't show a duration, so this is probably limiting the ability to seek/resume.

@softworkz, is it possible to have the file appear like a live stream?  I know this is better handled by Samsung as it has methods to update the live stream duration, but they only work if the live stream property is set (which might only be possible if it is delivered via hls).

We also see the same issue with live tv delivered via DirectPlay, it's not possible to seek backwards.

If I'm correct that this content would need to be delivered via HLS to support a live stream property, I think the next complication is that some of this broadcast content is interlaced which from recollection can't be delivered via HLS without converting to progressive.  Is that correct?

If we could fix this ability to resume/seek during playback of in-progress recordings, it would be a big improvement.  I know of users that resort to other clients for playback in these cases.

[SamES 890]

And of course, once you go to hls, then seeking is available anyway without any changes. (ie: adding a live stream property) but hls adds its own complications (ie: interlaced files, and other conversion dependencies)

The desired solution is to allow seeking while DirectPlaying in progress recordings, if that is at all possible. 

[softworkz 3326]

9 minutes ago, SamES said:

We always see this issue on Samsung and LG TV's as well.

DirectPlay on in-progress recordings don't show a duration, so this is probably limiting the ability to seek/resume.

The duration more effect than cause. The cause is that nobody knows the length of the file - neither the server nor the client. Anyway the size is permanently changing -(increasing), so there's never a valid answer to that question.

But let's start even a bit farther away. Even when there's no ongoing recording, it's already a pretty bad idea to do DirectPlay with *.ts files.

*.ts or *.mpegts - is not a file format - MPEGTS is "just" a stream format (and also not a streaming protocol). 

A ts file has no start and no end, no file header or trailer. It starts right away with the raw bitstream and ends in the same way

This is what separates it from all the usual container formats we know like MPV, MP4, AVI, etc.
When you DirectPlay any of the other files, the format parser knows at which position in the file (typically start or end) it can get certain information according to the container format specification. Besides information about streams and codecs and metadata, there's one very important element that clients are retrieving first: the "seek table" or "index" - formats often have different naming for the same things.

From the seek/index, table, the client will now with sufficient precision, at which byte offset it needs to start reading to hit a certain time. That's very important for seeking and data loading. Without index information, a client would often have to read the whole file from start to end and build its own index and that can be a lengthy process.
Many might remember those divx/xvid AVI files which could take endlessly to start playing, especially when on y network drive. In most of those cases it was about the index being corrupt or missing.

Now, ts doesn't have any index. The only change for a client to get at least _roughly_ an idea which time positions might correspond to which byte positions, is to read a piece of the stream and use the timestamps and byte size to calculate an estimated bitrate. With the bitrate it then tries to estimate which bytes ranges to to request from the server for skipping to a certain point in time.

There's another problem, though: there's no guarantee that the bitrates are constant. Bitrates are typically highly volatile in streams from IPTV providers and even channels from native TV often do not have constant bitrates (only the full mux must be CBR, the indiividual channels can fluctuate in bitrate, as long as the total sum is constant.

Need a writing pause. Will continue later...

 

[softworkz 3326]

11 minutes ago, SamES said:

And of course, once you go to hls, then seeking is available anyway without any changes. (ie: adding a live stream property) but hls adds its own complications (ie: interlaced files, and other conversion dependencies)

The desired solution is to allow seeking while DirectPlaying in progress recordings, if that is at all possible. 

TVnext uses HLS  only , no DirectPlay nonsense. And all these things will work. 

(but it's not HLS via ffmpeg like now.

[SamES 890]

10 minutes ago, softworkz said:

TVnext uses HLS  only , no DirectPlay nonsense. And all these things will work. 

(but it's not HLS via ffmpeg like now.

Great, thanks for the detailed explanation.  So it sounds like TVnext 'might' help with this scenario

[MBSki 1009]

40 minutes ago, softworkz said:

TVnext uses HLS  only , no DirectPlay nonsense.

I'm confused. I thought you said we should direct play. But now it sounds like you're saying we shouldn't. Which is it? If direct play shouldn't be used for TS, then shouldn't transcoding be forced for in-progress recordings?

[softworkz 3326]

31 minutes ago, SamES said:

And of course, once you go to hls, then seeking is available anyway without any changes. (ie: adding a live stream property)

It's not just changing VOD to LIVE. It provides a proper HLS live playlist which is constantly updating and provides actual segment times (rather than fictiona/constant values).
It also implements some parts of the HLS Low-Latency spec and another technique for really low latency. 

45 minutes ago, SamES said:

but hls adds its own complications (ie: interlaced files, and other conversion dependencies)

Which complications do you mean?

And can't the Samsung TVs play interlaced video? I mean that's core functionality for a TV device.

[softworkz 3326]

1 minute ago, MBSki said:

I'm confused. I thought you said we should direct play. But now it sounds like you're saying we shouldn't. Which is it? If direct play shouldn't be used for TS, then shouldn't transcoding be forced for in-progress recordings?

I never said that you should do something. I just told what TVnext does. But that's not transferable to current Emby.

[MBSki 1009]

Just now, softworkz said:

I never said that you should do something. I just told what TVnext does. But that's not transferable to current Emby.

Ok, but do you think Emby should be changed? How is this issue going to be fixed?

[emveepee 112]

I agree that ts files without an index aren't like m3u8, or finalized mkv or faststart mp4 but  I disagree this makes in-progress recordings significantly different than full recordings once enough time has gone by to get approximate bitrate for broadcast streams.  Certainly after 1 hour of football cncb should have a reliable seek point.  The server knows the clock time so the duration is known.  I know this isn't as bad since watching a comskipped in-progress recording is possible.

Martin

[softworkz 3326]

21 minutes ago, emveepee said:

I agree that ts files without an index aren't like m3u8, or finalized mkv or faststart mp4 but  I disagree this makes in-progress recordings significantly different than full recordings once enough time has gone by to get approximate bitrate for broadcast streams.  Certainly after 1 hour of football cncb should have a reliable seek point.  The server knows the clock time so the duration is known.  I know this isn't as bad since watching a comskipped in-progress recording is possible.

Sure, it works ok sometimes. But now, because it works sometimes,, it's not that bad?

A procedure in software development that doesn't provide a success rate of 99.9% or (usually even) higher is the definition of bad! And even 99.9 is still bad. Assuming a (fully fictional) user base of 500k, those 0.1% are still 500 users 

From a technical point of view this way of playback is an invalid method. It cannot work successful in a broad and general way. 

[MBSki 1009]

10 minutes ago, softworkz said:

From a technical point of view this way of playback is an invalid method. It cannot work successful in a broad and general way. 

Ok, so is someone looking into a fix for this issue?

[emveepee 112]

It works much more often that not, even if remuxed ts is better than broadcast ts. Many older native clients and Kodi clients for many backends dont' haven't had that problems that Emby has though so I can understand where you are coming from.  The only client for NextPVR that really needs m3u8 are Roku's and WebOS so I also understand you are looking for one solution.  

99.9 percent of a 3600 seconds is 4 seconds off most users can tolerate that kind of error, we aren't flying to the moon, and as I say it isn't that much different with finalized recordings.  The timestamps in some of these can make them equally not seekable and we don't have the clock time to help out.

Martin

Edited January 25, 2023 by emveepee

[SamES 890]

4 hours ago, softworkz said:

It's not just changing VOD to LIVE. It provides a proper HLS live playlist which is constantly updating and provides actual segment times (rather than fictiona/constant values).
It also implements some parts of the HLS Low-Latency spec and another technique for really low latency. 

Which complications do you mean?

And can't the Samsung TVs play interlaced video? I mean that's core functionality for a TV device.

I'll check tonight, but I recall that in the past we had an issue with interlaced segments being delivered via HLS.

Seeking into a file (say 60 minutes in) when starting from the beginning is slow if transcoding is involved as you can only seek as far ahead as there are transcoded segments.  Throttling doesn't help this as you can only seek so far.  However, from what you've said so far, I suspect TVnext would removes some of these issues.

[softworkz 3326]

1 hour ago, emveepee said:

It works much more often that not, even if remuxed ts is better than broadcast ts

That's because ffmpeg strips out most of the broadcast specific data which can easily confuse client players.

2 hours ago, emveepee said:

so I can understand where you are coming from.

I wasn't involved but I'm coming from place where you analyze the logic, do the math and when it doesn't calculate correct and reliably, then you look for a better way, even when many are saying, that it works for them. 

2 hours ago, emveepee said:

It works much more often that not,

"much more often than not" is fine for a hobbyist, but unacceptable for professional development.

2 hours ago, emveepee said:

The only client for NextPVR that really needs m3u8 are Roku's and WebOS

You seem to consider directplay to be superior over HLS streaming . But it's just the other way ronud,.

2 hours ago, emveepee said:

so I also understand you are looking for one solution.

No, it was about identifying the best possible solution without making any compromises. 
It will take you a while to see through everything and get the full picture. A while after release, I will talk a bit more about how it's working.

2 hours ago, emveepee said:

99.9 percent of a 3600 seconds is 4 seconds off most users can tolerate that kind of error

LOL, no.- 99.9% is the percentage of users for which it works without ever having any issue with that subject.

2 hours ago, emveepee said:

we aren't flying to the moon

No, but we're also flying IPTV where the strreams are often encoded with VBR. And then the segments you receive can look like this:

These ger more or les just concatenated when recording.

2 hours ago, emveepee said:

The timestamps in some of these can make them equally not seekable and we don't have the clock time to help out.

TVnext can do automatic PCR and DTS correction.

[softworkz 3326]

52 minutes ago, SamES said:

Seeking into a file (say 60 minutes in) when starting from the beginning is slow if transcoding is involved as you can only seek as far ahead as there are transcoded segments

How that? Emby doesn't always transcode from the beginning.
It starts at the requested position.
Or are you talking about a specific case?

[arrbee99 1551]

58 minutes ago, softworkz said:

A while after release, I will talk a bit more about how it's working.

Release. Release ? Someones talking about release. Please feel free to clarify the use of the 'R' word...

Edited January 25, 2023 by arrbee99

[neik 835]

@Luke

And another one where TVnext would help...

When, finally when will we get this to beta?!

[MBSki 1009]

@softworkz @ebr Can someone please answer my question? Is someone looking into a fix for this issue? It seems this thread is just to come up with theories, but no fix. We need a fix.

[emveepee 112]

9 hours ago, softworkz said:

You seem to consider directplay to be superior over HLS streaming . But it's just the other way ronud,.

@softworkzIn many ways for Live TV I agree with you, with adaptive HLS even more important for wider distribution.   However there is a class of users who consider channel zapping time important and want sub second response to channel changes without high end servers.

As this thread is specific to recordings, for finalized recordings I do not consider ts container superior to most containers, but I have not decided personally a preference between remuxing to mkv or out-of-spec faststart mp4   For in-progress  files their are obvious disadvantages to ts containers too but quick resume and bi-directional seeking are absolute requirements.  Perhaps if TVnext creates and its client support #X-BYTERANGE playlists that would be a solution but I actually consider these all direct play.

 

Edited January 25, 2023 by emveepee

[softworkz 3326]

9 hours ago, emveepee said:

@softworkzIn many ways for Live TV I agree with you, with adaptive HLS even more important for wider distribution.   However there is a class of users who consider channel zapping time important and want sub second response to channel changes without high end servers.

I belong to that class of users, and sub-second channel-changes has been one of the top-level design goals.  
As much as I'd love to explain how it works - you need to be patient a little bit.

[MBSki 1009]

12 hours ago, MBSki said:

@softworkz @ebr Can someone please answer my question? Is someone looking into a fix for this issue? It seems this thread is just to come up with theories, but no fix. We need a fix.

@ebr @softworkz I see responses to every other post but not this one. I think I've already asked 2x, but the 3rd times a charm I suppose. Can you please answer? Is someone working on a fix?

 

[SamES 890]

On 25/01/2023 at 10:28, softworkz said:

It's not just changing VOD to LIVE. It provides a proper HLS live playlist which is constantly updating and provides actual segment times (rather than fictiona/constant values).
It also implements some parts of the HLS Low-Latency spec and another technique for really low latency. 

Which complications do you mean?

And can't the Samsung TVs play interlaced video? I mean that's core functionality for a TV device.

I disabled all DirectPlay profiles and it has forced deinterlacing of the video stream for this in-progress recording when it delivers it via HLS. 

Even though the in-progress recording is already 30 minutes long, when I start playback from the beginning and want to jump to the 20 minute mark, I can only skip forward to the point where the file segments have been generated (ie: initially only a few minutes).  I also believe throttling makes this worse as transcoding stops/throttles and I need to keep skipping forward in small jumps to allow transcoding to continue.  Eventually I can get to the 20 minute mark, but it is not a good experience.  Effectively, the transcoding speed limits how far and how quickly I can skip ahead.

Edited January 26, 2023 by SamES

[ebr 14903]

14 hours ago, MBSki said:

@ebr @softworkz I see responses to every other post but not this one. I think I've already asked 2x, but the 3rd times a charm I suppose. Can you please answer? Is someone working on a fix?

 

In short, there is no easy fix.  We are obviously working towards improved functionality but its not going to happen overnight.