2016-06-05, 06:12
this recording available somewhere ?
2016-06-05, 06:36
2016-06-05, 07:04
(2016-06-05, 06:57)MrMC Wrote: no, I mean a sample of the video that shows the issue.
I shared temporary recordings of live TV stream made by NextPVR when the problem occured with sub3. sub3 already reviewed those and that is how he concluded what the problem is: Post: #48 (above).
2016-06-05, 07:14
maybe I'm just blind but I see no urls posted to grab those samples 
reason I ask is if it can be fixed, I'll fix it rather than push it off to someone else.
reason I ask is if it can be fixed, I'll fix it rather than push it off to someone else.
2016-06-05, 07:28
(2016-06-05, 07:14)MrMC Wrote: maybe I'm just blind but I see no urls posted to grab those samples
reason I ask is if it can be fixed, I'll fix it rather than push it off to someone else.
The original link to the recording expired on 31 May, The following link (at TransferBigFiles.com) to the recording expires on 9 June. KODI temporarty ts recordings of channel 760 when if fails to play
2016-06-05, 17:40
2016-06-06, 14:40
I doubt anything I do will inspire FernetMenta
I tested under MrMC fork, works just fine there. Sort of expected that as while renderer/player are from v17, it is using ffmpeg version from v16. We are in the middle of releasing MrMC v2.3.0. When that is out, I'll bump ffmpeg to what v17 uses and check again.
I tested under MrMC fork, works just fine there. Sort of expected that as while renderer/player are from v17, it is using ffmpeg version from v16. We are in the middle of releasing MrMC v2.3.0. When that is out, I'll bump ffmpeg to what v17 uses and check again.
2016-06-06, 16:47
No need to inspire me If sub3 is right and PMT is correct, which implies that ffmpeg parses it wrong, there is only one place to fix it:
https://github.com/FFmpeg/FFmpeg/blob/ma...ts.c#L1861
If accepted by ffmpeg we could add the fix to our fork until it will show up in a release. Don't expect me to fix it. My list of todos is rather long and has items with much higher priority.
If sub3 is right and PMT is correct, which implies that ffmpeg parses it wrong, there is only one place to fix it:https://github.com/FFmpeg/FFmpeg/blob/ma...ts.c#L1861
If accepted by ffmpeg we could add the fix to our fork until it will show up in a release. Don't expect me to fix it. My list of todos is rather long and has items with much higher priority.
2016-06-06, 17:59
(2016-06-06, 14:40)MrMC Wrote: I tested under MrMC fork, works just fine there. Sort of expected that as while renderer/player are from v17, it is using ffmpeg version from v16. We are in the middle of releasing MrMC v2.3.0. When that is out, I'll bump ffmpeg to what v17 uses and check again.
Yes, the recording of the live TV stream (that doesn't play in KODI as a live TV stream) plays in KODI as a video recording. However, if you were able to provide the contents of the recording to KODI as a live TV stream, then I believe it would not play with the KODI live TV player (which apparently uses the ffmpeg libavformat library to play live TV streams). Is there any kludge that you can do (as an experiment) that would allow you to play the recording of the live TV steam that does not play in KODI with the KODI live TV player?
If I understand sub3 correctly, then the contents of the temporary recordings of live TV streams that NextPVR makes are identical to the content of the live TV stream.
2016-06-06, 18:50
If they are truly the same internals, then that suggests a core regression. The same ffmpeg demux code would be used for both. Could be a format probe issue, live vs recorded are handled different to get faster 'channel' switch times for live.
Like I mentioned, can't really tell until MrMC fork bumps to v17 version of ffmpeg and I start poking around and yes, there are ways I can force live.
Like I mentioned, can't really tell until MrMC fork bumps to v17 version of ffmpeg and I start poking around and yes, there are ways I can force live.
2016-06-07, 05:49
(2016-06-06, 16:47)FernetMenta Wrote: If accepted by ffmpeg we could add the fix to our fork until it will show up in a release ...
OK. I submitted a FFmpeg problem report on this bug: #5616 new defect: ffmpeg fails to parse valid PMT with SCTE 0xC0 extensions. However, I am sure that I probably did not explain the problem with enough clarity for FFmpeg to fully get it. I know you are a busy guy FernetMenta, but could you take a moment to review the problem report and add a comment to it to make it clear? Thanks.
2016-06-07, 07:02
Looks good. Enough info for a dev to see the issue.
