G Kazaroth wrote:
> Glad to hear you got it working. Sleep is always a good thing. It keeps the mind sharp.
>
> Current status. XUMO is almost done. I was concerned about the EPG being way short, but found that I can load a full day worth of programs (from midnight to midnight UTC/GMT time). So, things are not that bad. Also, refactored the plugin code, since I now have three. More reuse code and less code per plugin.
>
> The issue with the skip forward and back has to do with discontinuity errors. Chances are an advertisement came into the feed and was not filtered out. I put together an initial filter, but it needs everyone's support to have it remove all the bad PTS packets. I am working to update some logging to help with detection so we can work together to fix it.
Great to hear about XUMO. I just wanted to let you know that I was able to repair a test recording that had this problem, by doing this:
ffmpeg -fflags +genpts -i original_file.ts -c copy -f mpegts temp.ts
And then Imoved (NOT copied!!) temp.ts over the original file. I found out a long time ago that if you ever try to copy a changed recording over the original in Tvheadend, Tvheadend completely loses track of it and it will no longer appear in your recordings list, so you have to move it.
ffmpeg did throw a bunch of "Packet corrupt", "Non-monotonous DTS in output stream 0:0", and "PES packet size mismatch" errors, but it did create a playable file that you can seek within.
Now that said, I don't know if you could do this in real time by changing the link in the mux. I have done other real-time filtering in a mux, but never within an automatic IPTV network. I think an automatic IPTV network would keep changing the link back to the original. But if it were just a regular IPTV network, and the mux URL was something like
http://127.0.0.1:5004/PlutoTV/watch/channel_id_number
Then what I would TRY in place of that is something like
pipe:///usr/local/bin/ffmpeg -loglevel fatal -fflags +genpts -i http://127.0.0.1:5004/PlutoTV/watch/channel_id_number -c copy -f mpegts pipe:1
(Assuming /usr/local/bin/ffmpeg is the correct path to the ffmpeg executable). I do not know if this correction can be made in real time, but maybe it would be worth experimenting with. If it does then perhaps there would need to be some way to specify a prefix such as "pipe:///usr/local/bin/ffmpeg -loglevel fatal -fflags +genpts -i " and a suffix such as " -c copy -f mpegts pipe:1" for each existing URL.
EDIT: I set this up on a couple of the muxes this way as a test, and am making a couple of test recordings later tonight. What I want to see is if the URL gets changed back to what it was because it's an automatic IPTV network, and if that doesn't happen, whether that makes the recordings seekable in Kodi. But I would really NOT want to have to manually change the links in over 200 muxes!
Alternately there's probably some way to do this in a post-recording process in Tvheadend but that would not help if you try to start watching the show before it has finished recording. And also I'm not absolutely certain this technique would always work. It would require a little extra CPU power for each stream being recorded, but ffmpeg is generally not CPU intensive in copy mode.
The funny thing is that recordings seem to play fine once you have fixed the the seek errors, there are none of the short pauses and no long black periods during commercials. So the way it works now is great for recordings, but I can see where it would be somewhat discomforting for live viewing. Still, since I hardly ever watch anything in real time, I would prefer not having to skip through some substitute content that would replace the commercials. So I am fine with the black or the freeze frame or whatever appears just before the commercial break in live viewing. But I do understand that others may think differently.
EDIT: I had originally included the -mpegts_flags system_b option in the ffmpeg commands but then I realized that's for a different issue entirely that's not relevant here.
