Posts by gedakc

    Each person is entitled to their own view of what is user friendly or not. Personally I find setting up both Tvheadend and MythTV quite complex. For day-to-day use I find both of these quite enjoyable, with a preference for MythTV as it has been better at deciphering and displaying Closed Captions embedded in OTA ATSC shows.

    From my experience using Kodi (5 years), Tvheadend (3 years), and MythTV (10 years), all of the front ends occasionally crash. However frontend crashes while watching a recording are extremely rare (at least for me). A restart of the frontend was all that I needed to continue watching. These frontend crashes have not adversely impacted the ability of the backend to record.

    Okay. Are you saying copy it to a USB 3.0 flash drive or USB 2.0 drive? Does it need to be a flash drive or can it be any drive? And once it is copied do you want me to access and watch the mkv file on the PI from the flash drive? Just for clarification.

    Should I also try to plug the enclosure into a USB 2.0 port instead of 3.0 to see if that fixes the issue? The enclosure is 3.0.

    I also plan on trying no buffer in advancedsettings.xml when I get the chance.

    My suggestion is to try a USB flash drive (either USB 2.0 or USB 3.0 - both are fast enough for HD video) in order to eliminate any potential problem associated with USB to SATA converters.

    Of course feel to try all of the above since you are trying to troubleshoot an issue.

    'Just a thought. If the content is from a TV Channel then the source material might have been broadcast in an interlaced format.

    If this is the case, then the "automatic" choice of de-interlacer in Kodi 18 Leia might be too demanding on your RPi3. On my RPi2 when watching a video I had to bring up the playback menu (M on a keyboard), choose the setting dialog (gear icon), choose Video settings and set the Deinterlace method to MMAL - Bob.

    If this works for you then you might wish to set as default for all media which is listed lower on the same screen.

    I've to add that HD contents aren't enjoyable at all with a lot of stuttering, probably because the RPi2 hasn't the needed resources or maybe there is some tweak to do I'm not aware of, I don't know.

    If the recordings are in MPEG-2 format (used in North America for Over-The-Air broadcasts) then be sure to Enable MPEG-2 Hardware Video Decoding on the RPi2.

    If you are using LE 9.x then be sure to set the Deinterlace Media Default to MMAL - Bob.

    Confluence Skin Instructions follow.

    Set Deinterlace Media Default to MMAL - Bob

    1. Navigate to TV -> Recordings

    2. Choose a 1080i PVR recording

    3. Press M to bring up playback menu

    4. Choose Film reel icon to display Video Settings dialog

    5. On Deinterlace method go through options and choose MMAL - Bob

    6. Navigate down to Set as default for all media and press Enter

    7. At prompt Set as default for all media. This will reset any previously saved values. Are you sure? respond Yes.

    8. Choose Close

    9. Stop playback with Square icon

    10. Navigate back to main screen.

    By using the MPEG-2 license and the Deinterlace setting MMAL - BOB I am able to smoothly play 1080i recordings on my RPi2.

    If you could get that grabber (tv_grab_zz_sdjson_sqlite) installed into LE it could be configured with ssh from another computer.

    The tv_grab_zz_sdjson_sqlite grabber source code appears to be written in perl. However, the perl language does not seem to be installed in LE. Because LE is "Just Enough OS for Kodi", I suspect that it may be a difficult time to convince the LE developers to add tv_grab_zz_sdjson_sqlite to LE along with the perl language and all of it's requirements. Then again I may be wrong so do feel free to ask the LE folks in the Feature Requests forum.

    'Glad to hear that you got it working.

    I'm no expert on the code base but I think that one has two options with this add-on for limiting the channels seen by tvheadend. One is limit the channels to those seen by an HDHomerun (Channel Filter). The other is to limit the channels using a File Based (Channel Filter) method. At least that is how I see it working.

    With the current code I think it comes down to the following:

    A: One SD Provider Lineup

    For users needing 1 lineup only, all of the options work (Channel Filter can be either HDHomerun or File Based). This is the situation where a user has a single TV signal source that has the TV listings covered by a single SD provider lineup. I think this would be the most common use case.

    B: Multiple SD Provider Lineups

    For users requiring multiple lineups, only the File Based channel filter will work. This means setting the sd4tvh Configure Settings and Options as:

    • HDHomerun Channel Filter to None
    • File Based Channel Filter to enabled

    This would be the situation where a user has more than one TV signal source and this necessitates the need for more than one SD provider lineup for the TV listings. This is the case that you and I have encountered. In your case it is driven by the need to support a mobile PVR that can move from location to location. In my case it is driven by the need to support channels provided by an Over-The-Air aerial, and by HTTP Live Streaming (HLS) over the Internet.


    I am grateful for the work that edit4ever did to pull together the sd4tvh add-on. While my primary PVR remains MythTV 0.27.6 running on Intel hardware with Mythbuntu 14.04, this add-on has enabled me to turn my RPi3 into a useful PVR. I only recently investigated the sd4tvh code base to fix a bug with SD listings missing artwork. Then I took it a step further to fix the add-on to work under LibreELEC 9.x. At this point the add-on works well for me.

    Fortunately the add-on is open source licensed so I could look at it and propose improvements. Please also feel free to contribute improvements.

    The following tests were performed with LE 8.2.5 as there are firmware issues with 9.2.3 on RPi3 (to be fixed in 9.2.4). Following is my testing and a suggestion to try.

    The sd4tvh Configure Settings and Options -> Options I'm using for this test are:

    • Number of Days to Download: 1
    • HDHomerun Channel Filter: Discover
    • File Based Channel Filter: disabled

    I discovered one anomaly while setting up the sd4tvh listings in that the TV -> Guide displays the old data from Over-The-Air PSIP: ATSC Grabber even after I configure sd4tvh. That is until I reboot. This might be a display issue bug in LE 8.2.5.

    More specifically for the testing I disable all the other EPG Grabber Modules, enable sd4tvh, run the internal EPG grabbers, select the EPG source channel/XMLTVID for each channel, then re-run the internal grabbers. After doing this I expect to see the updated SD listings; however what I see is the old ATSC EIT listings. That is until I reboot, at which point the SD listings magically appear in the TV -> Guide.

    Note that I have not even looked at the sd4tvh menus for Adding or Removing Schedules Direct Provide Lineups, or Adding & Removing Channels from Lineup. I have only set items in the sd4tvh Configure Settings and Options menu.

    The sd4tvh settings Options I'm using at this point are:

    • Number of Days to Download: 1
    • HDHomerun Channel Filter: Discover
    • File Based Channel Filter: disabled

    Note that I previously added 2 lineups to my SD account, and the ATSC stuff was in the first lineup. When I add another set of channels (IPTV for my test), I do not see the 2nd lineup listing of channels in the drop-down list of EPG source channels/XMLTVIDs.

    To get the 2nd lineup channels to appear I had to do the following:

    Set sd4tvh Configure Settings and Options as:

    • HDHomerun Channel Filter: None
    • File Based Channel Filter: enabled

    Then re-run the internal grabbers.

    Note that this put all of the channels into the drop-down EPG source list from the 2nd lineup.

    To shorten this list I think should have first used the sd4tvh Add & Remove Channels from Lineup menu entry.

    SUGGESTION:

    Can you try setting sd4tvh Configure Settings and Options as:

    • HDHomerun Channel Filter to None
    • File Based Channel Filter to enabled

    Optionally limit channels with sd4thv Add & Remove Channels from Lineup.

    And Re-run the internal grabbers.

    Then see if you can then select the 2nd lineup channels/XMLTVIDs for each channel EPG source?

    When you were at your new physical location, did you remember to update the tvh backend?

    More specifically, did you go to Configuration -> DVB Inputs -> Networks, click on the ATSC-T Network entry and then choose Force Scan?

    This would update the TV channels, but has the potential to create multiple entries for a single broadcaster (e.g., ABC).

    The method I would suggest would be to first remove the existing channels, services, muxes, etc., prior to scanning for the channels at the new location and then setting up sd4tvh. I've done this before and I have not lost access to prior recordings. By doing this I have not needed to re-run the setup wizard.

    To remove prior entries I suggest under Configuration -> General -> Base changing the User interface level from Advanced to Expert (remember to Save the settings changes).

    Then Delete the applicable channels, services, muxes, etc. under the following menu areas:

    • Configuration -> Channel / EPG -> Channels
    • Configuration -> Channel / EPG -> EPG Grabber Channels
    • Configuration -> DVB Inputs -> Services
    • Configuration -> DVB Inputs -> Muxes (Not sure if this one is required, but I do it for IPTV)
    • Configuration -> DVB Inputs -> Networks (I don't think this is required for OTA, but figured I should mention it)

    Note that I'm not an expert on Tvheadend so there might be an easier way to do this. There might also be steps I've missed. All I can say is that using steps similar to the above I have been able to remove and add IPTV channels without loosing normal access to prior recordings. These prior recordings remain in the Tvheadend database and are accessible from the TV recordings menu.

    'Hope that helps.

    If I change the zipcode in sd4tvh and re-select channels for the data I'm getting from SD, does it affect other setups like my home Mythtv

    Adding a lineup (with a different zip code) to SD should not adversely affect other SD clients. The other SD clients might see one more lineup when they query SD, but that shouldn't be a big hit on performance.

    However deleting a lineup that is used by another SD client would definitely have an adverse impact.

    When I had multiple grabbers enabled at the same time it seemed to me that the data from the last one run would be reflected in the listings. This was helpful if the OTA ATSC grabber listings were more accurate last minute. However, more often than not I found that the ATSC grabber listings were not as accurate as Schedules Direct. In the end I disabled all other EPG grabbers and left only the sd4tvh one enabled.

    I've been running tvheadend with sd4tvh on a Raspberry Pi 3B since November, 2017 and the system has been very reliable for me. The Kodi frontend crashes from time to time, but for the most part the tvheadend backend server continues recording shows. On very rare occasions I have discovered that somehow the whole OS crashes in a bad way, but I've also had these rare hangs in MythTV (my main PVR in the house) and with my normal Kubuntu desktop, so I don't think that any one of these is more unreliable than any other (not like the days when I used to run, or should I say keep rebooting Windows 98 ;)

    It's possible that the step where you "worked with sd4tvh addon and looked at the selected and deselected channels not changing anything" did make a difference.

    It seems that the filter.cfg file is written or re-written (I checked the timestamps) when entering the "Add & Remove Channels from Lineup" option. Depending on the settings this might make the difference between sd4tvh working or not.

    I think I always go into this last sd4tvh menu option. More testing is needed to see if this step is always required (at least with the current code in 0.3.4).