2024-05-18, 07:59 PM
The problems installing the PlutoTV Extra update per the method in the pinned forum page are repeatable. First off, the channels are duplicated unless they are first deleted from the Web UI. Also, the extras file is not mapped to the EPG running "python pluto.py extras". It appears that "python pluto.py install" is needed to trigger that, and until it is, no EPG updates are possible.
Otherwise, it's working as intended, though the timed incremental EPG update options were only briefly checked.
The suggestions on the documentation were just that, suggestions. If you find the feedback helpful, great, if not that's certainly your prerogative.
As far as Channels DVR, the idea was to eventually abandon most, if not all paid TV services. However, I've run across that forum before, and there are some great ideas there which can possibly be culled in order to resolve concerns with the current setup. Reinventing the wheel is not one of them, and as is, the PlutoTV Extra together with Streamlink, solves a lot of existing issues. The process of simply remuxing recordings is not going to fix much, but in the case of the gentleman who wishes to record from the bull riding channel, there may be some benefit in doing so. We've established that remuxing normalizes the PTS values and can therefore help with the calculation of a recording's duration. Another test from the bull riding channel, and ffprobe with the -show_entries packet=pts option demonstrates that it can smooth over corrupt packets as well, although this, in turn, may lead to short segments where initial stuttering remuxes into repeated playback. Pick your poison, as it were. But I've found that in some cases, the benefit outweighs the cost, which isn't much as long as no transcoding is occurring. On the other hand, what may be helpful for one program on one channel may not be for the next, as you've noted.
Frankly, I'm a neophyte when it comes to video streaming, and before the slugs method of parsing channel URLs and timed EPG updates became an issue, I'd moved on from exploring live TV playback possibilities. Piping in on the forum merely presented an opportunity to mention my findings from limited testing, and if it helps someone else reading along, it'll have added value.
Speaking of piping, the custom extra/batch method did not work for me. I wasn't expecting that it would after having previously run the combined command from the console (with and without the -re switch), sending the output to a file and noting that no file was actually written. Furthermore, the output is identical to what you've pasted above in the code box. The extras method did provide some additional info in the nrecord log, the main take being that NextPVR is waiting for data that is never received. It could be that the two executables running from the same process and simultaneously writing to stdout are colliding. Again though, the underlying issue is that Streamlink's output is being paused because of discontinuities, and my observation is that NextPVR will cease recording, and consequently end playback unless it's sufficiently short in duration or a timed recording is forcing it to continue.
Otherwise, it's working as intended, though the timed incremental EPG update options were only briefly checked.
The suggestions on the documentation were just that, suggestions. If you find the feedback helpful, great, if not that's certainly your prerogative.
As far as Channels DVR, the idea was to eventually abandon most, if not all paid TV services. However, I've run across that forum before, and there are some great ideas there which can possibly be culled in order to resolve concerns with the current setup. Reinventing the wheel is not one of them, and as is, the PlutoTV Extra together with Streamlink, solves a lot of existing issues. The process of simply remuxing recordings is not going to fix much, but in the case of the gentleman who wishes to record from the bull riding channel, there may be some benefit in doing so. We've established that remuxing normalizes the PTS values and can therefore help with the calculation of a recording's duration. Another test from the bull riding channel, and ffprobe with the -show_entries packet=pts option demonstrates that it can smooth over corrupt packets as well, although this, in turn, may lead to short segments where initial stuttering remuxes into repeated playback. Pick your poison, as it were. But I've found that in some cases, the benefit outweighs the cost, which isn't much as long as no transcoding is occurring. On the other hand, what may be helpful for one program on one channel may not be for the next, as you've noted.
Frankly, I'm a neophyte when it comes to video streaming, and before the slugs method of parsing channel URLs and timed EPG updates became an issue, I'd moved on from exploring live TV playback possibilities. Piping in on the forum merely presented an opportunity to mention my findings from limited testing, and if it helps someone else reading along, it'll have added value.
Speaking of piping, the custom extra/batch method did not work for me. I wasn't expecting that it would after having previously run the combined command from the console (with and without the -re switch), sending the output to a file and noting that no file was actually written. Furthermore, the output is identical to what you've pasted above in the code box. The extras method did provide some additional info in the nrecord log, the main take being that NextPVR is waiting for data that is never received. It could be that the two executables running from the same process and simultaneously writing to stdout are colliding. Again though, the underlying issue is that Streamlink's output is being paused because of discontinuities, and my observation is that NextPVR will cease recording, and consequently end playback unless it's sufficiently short in duration or a timed recording is forcing it to continue.
