tvheadend is confused about stream properties changing during recording
Added by Wild Penguin over 8 years ago
Hi!
I believe I may have mentioned this problem waaaaay back before, when I used .ts as the recording format. I've since changed to .mkv, but still have problems (sorry for not reporting back in ages, but I really record so seldom anything from TV).
The problem arises (or so I believe, but I may be mistaken!) when the dvb stream properties change during recording; the changes can be 1) video stream properties changin (resolution and often aspect ratio, too) 2) audio stream number and languag(s) changing and 3) subtitles being added and removed from the stream. On Finnish YLE DVB channels, this happens very frequenly - for a recording with any padding at the end and the beginning, uaually 2 times for each recording (especially anything not in Finnish, as there will be subtitles and additional audio streams and changing languages at the beginning and the end - and often the jingles are in HD, but other YLE promotional material might be in SD, 4:3, while the actual broadcast in 4:3, 16:9, SD or HD).
The behaviour with .mkv is that the stream is totally useless - it seems that the file has all streams interleaved with each other (with the beginning of each stream at "0" seconds, which is wrong)! Any player (including KODI) will choose the stream randomly after seeking. If one does not seek, the currently chosen stream keeps playing (but fast forward one second, and anything could happen). A previous version would split also .mkv's ,but KODI usually does not choose the right one (I can choose the right one manually with any other player).
With .ts, the recordings are at least in a usable format, so that the recording will be split each time the broadcast properties change (IIRC - haven't tested this recently). The problem with using KODI as a frontent is that always the wrong recording will be chosen (usually the newest one, i.e. the "padding" one just after the wanted programme - not, say the largest file).
I've had slightly different behaviour/variances of the above when using KODI previously, but never during the las year, I've had a setup where KODI would actually choose the right file (or, having any control over which file to play, or playing from the beginning to the end of a multi-file recording).
My question is this: I've had the same problem for > 1 year now, and I though this may be a core functionality/bug that must be bothering someone else, and perhaps will be fixed later. As that is not the case, my question is this: Am I the only one having these problems? Is there anyone here recording DVB channels that have similar broadcasts (i.e. changing video/audio/subtitle during recording, or, maybe even recording YLE cahnnels)? Do you have these problems, or does tvheadend (and KODI, if you use it) handle things gracefully?
The current behaviour I have is with 4.1-2109~g189dcb6 , but I've had this with several older official releases in Arch Linux, too, during the last year.
I can provide a recorging demonstrating the issue (but the current "interleaved" recording I have is 3GB, but I could try to create a smaller test recording).
p.s. as the current very weird .mkv I've got applies to any player, I'm posting this in General instead of "XBMC as frontend" section
doctorwho-mkvinfo.txt (3.25 KB) doctorwho-mkvinfo.txt | A mkvinfo > txt file |
Replies (3)
RE: tvheadend is confused about stream properties changing during recording - Added by Mark Clarkstone over 8 years ago
Ville Aakko wrote:
Hi!
I believe I may have mentioned this problem waaaaay back before, when I used .ts as the recording format. I've since changed to .mkv, but still have problems (sorry for not reporting back in ages, but I really record so seldom anything from TV).
The problem arises (or so I believe, but I may be mistaken!) when the dvb stream properties change during recording; the changes can be 1) video stream properties changin (resolution and often aspect ratio, too) 2) audio stream number and languag(s) changing and 3) subtitles being added and removed from the stream. On Finnish YLE DVB channels, this happens very frequenly - for a recording with any padding at the end and the beginning, uaually 2 times for each recording (especially anything not in Finnish, as there will be subtitles and additional audio streams and changing languages at the beginning and the end - and often the jingles are in HD, but other YLE promotional material might be in SD, 4:3, while the actual broadcast in 4:3, 16:9, SD or HD).
The behaviour with .mkv is that the stream is totally useless - it seems that the file has all streams interleaved with each other (with the beginning of each stream at "0" seconds, which is wrong)! Any player (including KODI) will choose the stream randomly after seeking. If one does not seek, the currently chosen stream keeps playing (but fast forward one second, and anything could happen). A previous version would split also .mkv's ,but KODI usually does not choose the right one (I can choose the right one manually with any other player).
With .ts, the recordings are at least in a usable format, so that the recording will be split each time the broadcast properties change (IIRC - haven't tested this recently). The problem with using KODI as a frontent is that always the wrong recording will be chosen (usually the newest one, i.e. the "padding" one just after the wanted programme - not, say the largest file).
I've had slightly different behaviour/variances of the above when using KODI previously, but never during the las year, I've had a setup where KODI would actually choose the right file (or, having any control over which file to play, or playing from the beginning to the end of a multi-file recording).
My question is this: I've had the same problem for > 1 year now, and I though this may be a core functionality/bug that must be bothering someone else, and perhaps will be fixed later. As that is not the case, my question is this: Am I the only one having these problems? Is there anyone here recording DVB channels that have similar broadcasts (i.e. changing video/audio/subtitle during recording, or, maybe even recording YLE cahnnels)? Do you have these problems, or does tvheadend (and KODI, if you use it) handle things gracefully?
The current behaviour I have is with 4.1-2109~g189dcb6 , but I've had this with several older official releases in Arch Linux, too, during the last year.
I can provide a recorging demonstrating the issue (but the current "interleaved" recording I have is 3GB, but I could try to create a smaller test recording).
p.s. as the current very weird .mkv I've got applies to any player, I'm posting this in General instead of "XBMC as frontend" section
Please do open a bug report and include a mux sample, not a recording sample. Wget a play link from the muxes tab, choose a mux with a service that is not encrypted and has the issue you describe..
RE: tvheadend is confused about stream properties changing during recording - Added by Robin Mitra about 8 years ago
I have the same problem, also, I believe reported elsewhere a while ago.
In my case it is the fact that audio streams get added to a program.
This issue is so old, and is only solved properly in WMC (in 2005 !!!) . DVBLink also had ths issue, but it got resolved about a year or so ago.
wrt posting a mux : that could be problematic, since the channels in question are encrypted. A .ts recording of the program should work, but that you already got above.
Apart from tvh doing the right thing... Kodi can't handle the stream change. So even when watching with KODI what happens is that the live video freezes for a 2-3s, then the audio is gone. I have to change channel then get back to get the new audio streams.
So I don't know if this tvh only or tvh+KODI that needs to be fixed.
RE: tvheadend is confused about stream properties changing during recording - Added by Steam Guy about 8 years ago
I have the same problem but it seems to be a KODI problem. I can play the recorded .ts file with VLC (no problems skipping forward). With KODI it doesn't matter if i play the recording through the plugin or directly from the file on disk. Skipping forward always sends me back to menu and total length of the file is 26 hours+ although the recording is just 3 hours.