Turns out that my Raspbian issue was a configuration issue (somehow got set to 64MiB of video memory), and my Firestick issue was a Wifi issue (Firestick no likey high 5GHz channel numbers, switch to 36 if you can), so without any further delay ...
Version 1.2.0 (Build 6415)
https://github.com/djp952/pvr.hdhomerun ... /Downloads
- Update libhdhomerun library to version 2017.06.12
- (Jarvis) Fix disabling of seek for Live TV when "Stream LiveTV channels directly from tuner device(s)" is enabled
- Remove custom addon callback implementations in favor of the standard ones provided in Kodi source code
- Update MPEG-TS stream implementation to support Recorded TV as well as tuner-direct Live TV streams
- Detect and remove MPEG-TS SCTE PIM (0xC0) table when inserted before the PMT (0x02) table in the same PSI packet
- Add "DVR stream read operation timeout (milliseconds)" advanced option
- Add "DVR stream read operation minimum size" advanced option
- Add "DVR stream ring buffer size" advanced option
I don't have a lot of time tonight to update the Wiki, so I'd like to give some information about the bolded items above here:
Update MPEG-TS stream implementation to support Recorded TV as well as tuner-direct Live TV streams
This is what makes it "1.2.0" as opposed to "1.1.2". All HDHomeRun DVR content is now streamed via the internal stream code for this PVR. The old versions used a deprecated Kodi feature to just pass it a URL that is slated to be removed, so this change was inevitable. Note that based on feedback from a test version of 1.2.0, I did revert the way it handles threading and synchronization to the same basic models prior versions used since it was more stable approach. Also note that this is a breaking change for "DS Player", it will no longer function as it relies upon that deprecated feature to be used by the PVR Client. Version 1.1.1 is the last build for DS Player (sorry!!)
Detect and remove MPEG-TS SCTE PIM (0xC0) table when inserted before the PMT (0x02) table in the same PSI packet
This is the big fix everyone has been hoping for, myself included. This change examines all mpeg-ts packets as Kodi reads them and detects the packets giving us problems with streams starting but never playing. I plan on putting the nitty-gritty in the Wiki, but the shorter version is that in North America, cable channels add information to indicate when local commercials can be inserted. If a channel chooses to combine this information in the same packet as the Program Map Table (PMT), ffmpeg, the decoder Kodi uses, can't handle it - it's a bug. This causes ffmpeg to examine the streams to figure out what they are; if this takes too long it gives up. The change I made simply removes the 'bad' data from the packet before sending it to Kodi, and seems to have completely resolved the problem!
Add "DVR stream read operation timeout (milliseconds)" advanced option
New tuning option. This controls the amount of time to wait for stream data to be available before returning a zero to Kodi, which generally stops the stream -- in the Kodi log you'll see something like "stream stalled". The default is 2500ms. The old non-configurable default was 5000ms. In reality if you can't stream a single packet of data in 2.5 seconds your experience is already pretty miserable, but you can tinker with this if you'd like.
Add "DVR stream read operation minimum size" advanced option
New tuning option. The idea behind this one is for the folks that report streams start and then buffer fairly quickly, then are fine. That indicates a condition known as starvation, there isn't enough data coming in fast enough to satisfy Kodi. By telling the PVR to wait until more data is available this condition might be avoided. Note that in reality this is more of a "hint" than a hard limit, and is adjusted on the inside to ensure whole mpeg-ts packets are returned. If you set this too high, it will take longer for your live streams to start and longer to recover after a seek operation. The old value here would have been zero, the new default is 1KiB, and you can tinker with this too to see if helps anything for you.
Add "DVR stream ring buffer size" advanced option
New tuning option. Not complicated, this is the amount of memory used as a ring buffer to hold the stream data as it comes in. It may be tempting to increase but in reality has little value if you do; the best case I could make for a larger buffer is that micro-seek requests from Kodi (which happen a lot more than you'd expect) may be able to be fulfilled with the data already in the buffer. The old code was fixed at 4MiB, which is still the default now. To get a read on how much that is in reality, 4MiB equates to about 2 seconds of an HD stream. Even quadrupled to 16MiB, you're still not going to get a hit for a -10 second video seek. I suppose if you play a lot of SD content maybe it's useful to crank it up, but honestly 4MiB should be quite sufficient.
I will make every attempt to get the Wiki documentation fully updated ASAP.