[Approved] Fix for stuttering/corrupted streaming of live tv (9 Viewers)

[disaster123]

AW: Re: AW: Fix for stuttering/corrupted streaming of live tv

Interesting discussion: changing the handling of the tsreader would also make "Fortherecord" users happier, I think. Especially with UNC stuttering occurs, when a new timeshiftfile is created. Rtsp is also not running flawless, it starts to freeze or stutter after a while. With vlc the rtsp stream runs as it should.

I did an experiment with creating only a single "looping" timeshift file in Argus, and while this works fine server-side the problem is that MP's tsreader can't handle this It stops playing the moment the file "wraps". So modifcations would be needed so it understands that the current-position offset will actually wrap back to the beginning of the same file.

I do like the simplicity of this approach -- and a single looping file may also bypass the UNC problems some of you are seeing.

Yeah that's correct i like that idea too. But i think it isn't as easy as it claims to be. You've also to change the rtsp streaming stuff, tswriter and you need an additional file to record the start / loop position for tsreader - as it scans the file always from beginning to the end for pcr packets to calculate the estimated duration.

Also somebody should implement skipping of wrong / false packets in tsreader without crashing the whole MP GUI. At least MP does not react to anything anymore when tsreader doesn't get correct packets ;-(

@miroslav
Have you found a solution for rtsp or do you have any news for us?

 

[dvdfreak]

Yes, the most important change would be a different calculation of the duration. Before the file wraps the first PCR will be at the beginning of the file, like it is today.

But once the file wraps the first PCR will actually be right behind the current file-offset.

And the last PCR will be before the file-offset in both cases. All in all not such a major change I would assume.

Changing tswriter is not an issue from my point of view, I have already changed Argus' live-tv-writer, so that part is done

EDIT: regarding that extra file: .tsbuffer could still be used for this purpose, but it would simply contain only one .ts file. Then the files-removed/added counters could be used to detect if the position has wrapped or not (1 = not wrapped yet, > 1 = wrapped). They then become some sort of wrap-counter rather than really indicating a file-add/remove.

 

[miroslav22]

Hi,

Sorry not had time to look at RTSP yet, i'm busy with something else for another day or two. I might have to prioritise other bugs in the mantis first so 1.2.0 beta can be released, but i'll see what the situation is.

It might not be so difficult to change tswriter/tsreader to use a single rolling file. It could just need a change to stop it closing and re-opening the file on both sides.

 

[disaster123]

AW: Re: Fix for stuttering/corrupted streaming of live tv

Interesting discussion: changing the handling of the tsreader would also make "Fortherecord" users happier, I think. Especially with UNC stuttering occurs, when a new timeshiftfile is created. Rtsp is also not running flawless, it starts to freeze or stutter after a while. With vlc the rtsp stream runs as it should.

I did an experiment with creating only a single "looping" timeshift file in Argus, and while this works fine server-side the problem is that MP's tsreader can't handle this It stops playing the moment the file "wraps". So modifcations would be needed so it understands that the current-position offset will actually wrap back to the beginning of the same file.

I do like the simplicity of this approach -- and a single looping file may also bypass the UNC problems some of you are seeing.

Yes, the most important change would be a different calculation of the duration. Before the file wraps the first PCR will be at the beginning of the file, like it is today.

But once the file wraps the first PCR will actually be right behind the current file-offset.

And the last PCR will be before the file-offset in both cases. All in all not such a major change I would assume.

Changing tswriter is not an issue from my point of view, I have already changed Argus' live-tv-writer, so that part is done

OK that's correct 4TR has it's own engine ;-) There were already a mantis issue in the past to change the stuff to ONE rolling file. Sadly it was closed.

0001862: Change timeshift file handling to have only 1 file per user session which is preallocated - MediaPortal Bugtracker

 

[miroslav22]

Yes forget what I said, didn't know this had been raised before. Looking at the technical discussion it would take a massive amount of work to get this to work properly

 

[disaster123]

AW: Fix for stuttering/corrupted streaming of live tv

miroslav22
As we (normal users) are not able to look into that. Could you tell us something about what is needed? At the moment i can't see why it would be so much work.

Changing tswriter would be quite easy. Tsreader also doesn't seem to be too complicated. Then we have the streamingserver but there we can rent a lot of code from a working tsreader.

In tsreader we have the duration stuff - there it would be a little bit complicated to always find the startPCR when the file rolled over the rest should be easy.

 

[dvdfreak]

Yes forget what I said, didn't know this had been raised before. Looking at the technical discussion it would take a massive amount of work to get this to work properly

You really think so? I can't speak for tswriter, but I did my changes to the Argus recording engine last night in less than 30 minutes.

And making tsreader understand a single .ts file (still handled through a .tsbuffer file) doesn't sound like total rocket-science either, it's probably only the duration calculation that would need to be modified (as outlined above).

Or what am I missing?

 

[miroslav22]

I've only had time to glance at it but the PCR handling looks like it will be more difficult with a single file. Rollovers, seeking, calculating total duration look like the main factors.

Again i've only glanced at it.

 

[tourettes]

Re: AW: Fix for stuttering/corrupted streaming of live tv

In tsreader we have the duration stuff - there it would be a little bit complicated to always find the startPCR when the file rolled over the rest should be easy.

Seeking might cause some unexpected issues since it is using binary search for searching the actual PCR. I would assume that it wont cope the case where PCR values are bigger in the TS file than they are at the end (after all binary search requires "continuos" data).

 

[tourettes]

Yes forget what I said, didn't know this had been raised before. Looking at the technical discussion it would take a massive amount of work to get this to work properly

You really think so? I can't speak for tswriter, but I did my changes to the Argus recording engine last night in less than 30 minutes.

And making tsreader understand a single .ts file (still handled through a .tsbuffer file) doesn't sound like total rocket-science either, it's probably only the duration calculation that would need to be modified (as outlined above).

Or what am I missing?

Since this is benefiting all 4TR multiseat (MP based) users and is not even supported by the team itself (SMB hasn't ever been a supported mode for multiseat) maybe you could have a peek on the TsWriter/TsReader code?

I understand if you aren't, but please understand if I am not that keen for improving the non-supported use case