Whaaaaaaatttt … an actual version number bump? Patented djp952 extremely lengthy release notes diatribe to follow...
Version 1.3.0 (2018.08.04)
https://github.com/djp952/pvr.hdhomerun ... /Downloads
>> PLEASE UPDATE THE FIRMWARE ON ALL YOUR HDHOMERUN DEVICES <<
- Change internal channel identifier encoding to indicate tuner-direct only streams that cannot be accessed via an HDHomeRun RECORD engine
- Fix bug causing "DVR stream read operation minimum size" to default to 1KiB instead of 4KiB if not explicitly set
- Fix bug causing tuner-direct streams to improperly be reported to Kodi as zero length and not real-time
- Display notification when a live stream seek operation fails and attempt to recover the stream at the last known position
- Disable stream packet filtering when misalignment of MPEG-TS packets has been detected
- Add support for Kodi Timeshifting display indicators when playing Live TV streams using first detected MPEG-TS stream with PCR values
- (Krypton) Remove "Disable reporting of real-time MPEG-TS streams" advanced setting (performance concern)
- Trigger a Kodi error notification when a Live TV or Recorded TV stream cannot be created successfully
There is an important fix in here for tuner-direct streams and some new bullet-proofing/reporting for when bad things happen, but the main feature here is (as requested) finally enabling the Kodi "timeshift" UI elements.
This is a ".0" release, so as always while I do my best to give you guys and gals a quality product, weird things might happen. The version number got bumped due to a change in the way the internal PVR channel identifiers are encoded, which invalidates the existing channel identifiers. When you install this a new PVR database will be created and everything will be re-loaded from scratch. I was careful to not allow any overlap with existing settings and user data, so if you have to roll back to 1.2.x the old PVR database should pick up where it left off. "should™".
Enabling the requested timeshifting UI elements is, as mentioned, the main new thing here. It's a bit of a hack internally -- to really do this properly the main audio/video streams need to be examined (demuxed) so you can keep track of all the timestamps. I still have no desire to write a demuxer or think I could do any better than ffmpeg/Kodi does, so I came upon a compromise: I find the first program in the stream that has any timestamps and assume they will be valid for all eternity. Clearly this assumption will not be valid in all cases, so I added things to detect that and cease reporting the timeshifting data to Kodi for the duration of the stream. In practice, the assumption seems pretty valid -- I only actually ran into problems with ATSC streams that dropped out on me.
An inability to report the timeshifting data to Kodi is currently a silent failure, you won't see anything in the logs or get any messages from the PVR. It will simply stop working and suddenly behave like 1.2.x did. Kodi asks for this information A LOT, like really really A LOT, and I decided that it was better to just fail than to take the time to report what happened - every millisecond counts when a Live stream is playing over Wifi
For the same performance reasons I didn't add an option to turn this whole new feature off, Kodi asks so frequently the act of checking the setting was a detectable performance impact.
I also added a 1-second amount of 'wiggle room' on the determination of when a live stream is being timeshifted. For the same performance reasons as above with settings I didn't make this configurable, but if you run into live streams showing up as "Timeshifting" when you are sure you are back to live, let me know and we can bump this value up to account for stream latency.
There are also a couple new notifications in this release. If the PVR can't start a stream for some reason you will get a notification with the basic message, and you will also get a notification if a seek operation fails. When a seek fails, the new behavior is to try and recover it from the last known position so you can at least keep watching it. In Kodi 17 "Krypton" only (does not affect Jarvis/Leia) the PVR will allow you to try and seek a tuner-direct stream because of a Kodi bug that prevents you from pausing (remember this one?) so that should cause an error message yet keep going, and in testing I found a concern with seeking streams that are already playing on another device, you get an HTTP 503 error. SiliconDust knows about this one and is fixing it for us, but for now you will get an error notification and it will restart the stream from the last known position. Decent workaround?
What else is in here … good gracious I type a lot … I added a flag to completely stop the packet filtering and timestamp reads/checks if a stream becomes misaligned. While perhaps impossible or at least extremely rare, a corrupt or misaligned stream that happened to have the proper sync byte in the right place (0x47) would still try to remove the problematic SCTE PIM table(s) from the PMT packets. This would just screw up the stream even more on you if it succeeded. I really don't think this could ever happen, but now it's prevented. Along the same lines if a misalignment is detected the checks for the timestamps to deal with the timeshifting UI are also turned off.
I removed the Krypton-specific "Disable reporting of real-time MPEG-TS streams" advanced setting for performance reasons. This was a very specialized setting to begin with to deal with an audio sync issue in the past. The audio sync issue can be corrected with Kodi settings instead of this option, so I finally killed it. At some point I will update the wiki with what we collectively learned there and the proper Kodi-based solution.
Update all of your HDHomeRun devices
, give this version a try, let me know what you think or any problems you run into. It's officially the "best release ever" .. until the next one
PS: A Leia build is still MIA/DOA ... I'll do what I can to get something for the new "Beta 1" working ASAP.