Catchup TS stream freeze on seek
#1
Hi everybody,

I am trying to use pvr-iptvsimple + inputstream-ffmpegdirect to play streams that I recorded from DVB-T.
I used to record some TV channels as slices of one second of Mpeg TS files and then I can play them and seek backward and forward (time shift).
The server part is very simple : it take the date of the first slice to send and transmit all the following parts as a signgle stream via http.
Each slice contain a multiple of 188 bytes which is the size of a DVB packet so it begin and end on a packet boundary.
This works very well with Mpv or Vlc so I know that the main concept is ok.

I tried this with kodi 19.4 on Ubuntu 20.04 using the team-xbmc-ubuntu-ppa-focal packages and it worked pretty well : Streams play flawlessly,  seek work most of the time and pause/resume too.
The only problem is that sometimes, when I seek the player freeze and I have to seek again until it accept to play the stream.
Same problem at resume after pause : sometimes playback freeze just after having consumed the buffer (it pays well about 5secs then stops). I can resume by seeking but every now and then it crash and restart kodi !

When this happens, the log says :  "ERROR <general>: ReadPacket - Error demux packet doesn't belong to a valid stream"

There is my m3u config for one channel :
#KODIPROP:inputstream=inputstream.ffmpegdirect
#KODIPROP:inputstream.ffmpegdirect.is_realtime_stream=true
#KODIPROP:mimetype=video/mp2t
#EXTINF:0 catchup="append" catchup-source="&cutv={Y}-{m}-{d}T{H}:{M}:{S}" catchup-days="1" tvg-ID="France3.fr" tvg-name="France 3" tvg-chno="3", France 3
http://dev-server.mltv/Server/Stream.php...pe=catchup

I tried to google this issue very hard but I didn't find any clue of what's going on :-(
Any advice would be greatly appreciated !

BR.
Olivier.
Reply
#2
That sounds like a reasonable TS streamer to me. Technically it should work, most likely what is happening is that stream itself changes between files and somehow that change information is lost.

That’s what the error means. It got a packet but has no information about that stream so it keeps trying.
Maintainer of Enigma2 PVR addon: repo, docschangelog
How to create a full debug: here
Reply
#3
Thank you very much for replying.

I am not sure to really understand the point ...

When you says "The stream change between file" do you mean that I must restart on the same PID when I seek ?
That is : on the TS stream there are many elementary streams, let says PID 120 is for video and 110 for audio. Do you mean that If the demuxer was reading a 110 packet when I seek I must restart with a 110 too after seeking ?
If this is correct, is there a way for me to figure what PID it wants ?

I by saying "The stream change" you mean that the whole stream is not the same or all PIDs changed, that is not the case because all the stream files come from the same DVB program and it happens event if I seek very next to the current position (says 10 or 30 secs) in the same show (that is : not from, let say a talk to an ads). Furthermore, using dvbsnoop I was able to check that nothing changes between two slices (same codces, same PIDs, same time base etc ...)

Could you please explain more precisely what you mean by "The stream change" or, better, explain how the stream should be to fix the "demux packet doesn't belong to a valid stream" problem ?

If that may help, I can edit the code and put more debug into it to to get more info about the wrong packet .... If you tell me where (and what) to look for.

BR.
Olivier.
Reply
#4
I’m afraid I don’t know. All I remember is that when I built the local timeshift feature the error you are showing only appeared when I incorrectly read the underlying segments of stream data. Usually as I corrupted the data as I wrote/read it in the wrong order.

But remember I was insulated from the underlying stream packets by kodi’s packets so it’s not quite the same thing.
Maintainer of Enigma2 PVR addon: repo, docschangelog
How to create a full debug: here
Reply
#5
Ok, I will keep investigating and using MPV as external player in the meanwhile.

That said, I though to a possible workaround: Do you think it would be possible, instead of trying to feed de demuxer with the time shifted stream, to just stop and restart the player exactly as if one has changed the channel ?
I mean, when you change channel, the player obviously stop reading the current stream then open the new one and start reading it. What I propose is to do the same on pause/resume and, why no, on seek.

If you think that this is technically possible I may do it myself if you point me on a direction to do so (that is << you should modify this method in that class and so on ... >>)

Br.
Olivier.
Reply
#6
I'm no expert but if you say VLC works but Kodi doesn't sometimes I'd guessed it something to do with ffmpeg parsing the packets and not finding the expected PID when timeshifting. Maybe VLC has more tolerant code when parsing the steam?

Since you say it happens occasionally I would run Kodi in debug mode and try to trigger the error. Extract the timeshift URL used that triggered the error from the logs. I'd then use that same URL and run it through ffprobe tool and look at packet output to see if that shows up any errors. It would also confirm your streaming server is sending on DVB packet boundaries.
Reply

Logout Mark Read Team Forum Stats Members Help
Catchup TS stream freeze on seek0