Tvheadend

Paul M , I just checked that the current epg was causing the json error before upgrading to the latest version of tvh_epg. I am pleased to confirm that the epg tab now displays without the json error :-)

I will see how things go at other times but so far looks good, well done!

If the error returns later I will send you the raw data as requested.

Thanks again Paul!

that's great, thanks for letting me know.
setting json strict loading off is a bit of a hack, it would be better to find out why TVH is sending bad json. It could simply be that the raw EPG data from FreeSAT is actually bad, and it would be necessary to write my own decoder to turn the raw text from the EPG into the Python3 unicode encoding used by default.

If it helps I attach an extreme debug log. On the old tvh_epg this produced the json error for PBS America, channel 91 (DVB-T).

Hi,
I think it was a different json loads, so please comment out the extreme debug you now have.

update to the latest version from git hub, and turn on the extreme debug at line 734

then please refresh the EPG page then quote the table cell contents for the channel whose EPG data would give the bad json, that would be great.

Hi Paul M

I'm hoping I've followed the right process here. To clarify, the last two updates of tvh_epg produce no EPG errors since you changed the json load parts. So, I went back to the older version and determined that at the time of testing, channels 91 and 32 produced errors (I disable in TVHeadEnd the first channel that gave an error, 91, tvh_epg then shows the next error channel down, ie 32. With 91 and 32 disabled, there was now no errors and the full epg list displayed).

I then re-enabled 91 and 32 and used the latest tvh_epg but with line 734 # tag removed. I have now saved and attached the extreme debug data for these two channels.

Hope this makes sense!?

Another question please, I used tvh_epg yesterday to successfully record a programme. This recording will playback in VLC using the link generated by tvh_epg. However, when clicking on the Chromecast icon in the recording tab, Chromecast will not play it. Is this still an area your working on, or should it have played on Chromecast? EDIT: Resolved, just realised I needed to setup my recording stream profile, eg to "chromecast", in TVHeadEnd.

I will take a look at the debug text, thank you for doing that.

Sadly, yes, you can't chromecast recordings because persistent auth doesn't work, and I couldn't find a way to add a username/password to the URL that worked :-(
I've got a bug report on it: https://tvheadend.org/issues/5781

which has garnered no attention. I wish I was a better developer so I could have a go at fixing it myself!

Interesting your comments on recordings as I've now managed to get mine to playback on Chromecast. I'm wondering if its a Video Codec issue? My details;

Working example from the Recording / Chromecast page which displays (have changed user/password);

Debug: uri "dvrfile/1b7a41bd30467559beb74cd3df2cbfa1" 
fullurl is "http://user:[email protected]:9981/dvrfile/1b7a41bd30467559beb74cd3df2cbfa1?profile=chromecast" 

This in turn will playback the recorded file;

"/home/hts/Cruising With Jane McDonald.mkv" 

To get this to work I went into TVHeadEnd - Configuration / Recording and changed the Stream Profile to chromecast. This Stream Profile is setup to use the Video Codec "libx264: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10".

Without doing this, the recorded file was saved with the extension .ts which would not play on Chromecast.

I should point out that I'm still on TVHeadEnd "HTS Tvheadend 4.2.8-36~g5bdcfd8ac" as I never was able to build a 4.3 version with working Video Codecs :-(

Hope this info helps.

EDIT: Now I'm lost, just tried to send a recording to chromecast and it will not work tonight!

Paul

I hope you don't mind me sharing my thoughts and trials to get recordings to play on Chromecast. Although I don't understand why it was working for me and now nothing, I thought about trying to do something with the recorded .mkv file itself which the chromecast profile saves.

I therefore tried using Apache to point Chromecast to the file rather than going through TVH. That is, I changed the recording profile so it saved in the same location as tvh_epg.py and then sent to chromecast;

http://192.168.1.183/recording_filename.mkv

Using a pychromecast example file (attached for reference), Chromecast then played the recording fine.

Could phy_epy.py send this format link as a workaround for now? A bit rough and ready but it seems to work :-)

Thanks

I'm very pleased for any ideas you can come up with to make it possible to chromecast recordings.

I had tried setting the url of the stream to be http://user:[email protected]:9981/dvrfile/blahblah?profile=chromecast
That didn't work with VLC unfortunately. I also found that VLC somehow cached the username and password and if you accidentally did this, then getting vlc to forget seemed impossible, and thus further testing was hampered.

It should be possible to transcode the .ts files into a format that Chromecast will play, mp4 has worked for me (I also have a project to provide a web interface to get_iplayer, and am adding chromecast to that). I would guess that it should be possible to have the cgi-bin initiate a transcode of the .ts file , it can run ffmpeg to read the .ts file from tvh directory and write to somewhere in the document tree.

Here's an example helper script to convert .ts to .mp4, I could make tvh_epg.py call it, once I can figure out the API to convert the recording ID to a filename.

https://github.com/speculatrix/web_get_iplayer/blob/master/ts-to-mp4.sh

Thanks for the feedback Paul.

I might be missing the point on the .ts files. On my system these were generated by the recorder if using the original "default" recording profile. In this profile though I changed the "stream profile" from "pass" to my "chromecast" profile, to take care of the necessary transcoding. Therefore it now saves .mkv files (or could be set to MP4), readily compatible of course with most media players without further "work". Therefore no post recording transcoding is needed and readily playable by Chromecast / VLC etc?

Sorry if I've missed something.

I seem to have discovered why I could send recorded files to Chromecast and then it stopped working. My issue is all around the user profile settings. It seems that when trying to watch a recording, Chromecast is not using the profile specified in the link, but the one highlighted in the attached screen shot.

By pure chance, I now know that unless this profile has at least the "Video Recorder:" / "View All" ticked, Chromecast will not work!!

It will still not play .ts files, so the recorder must save as MP4/mkv. This is probably best though as these file formats should be smaller in size than raw .ts

It will be interesting if this is what is happening on your setup Paul?

Thanks David G for persisting.
It's a good discovery that the profile in the link is ignored, I thought it was because of credentials being broken (user:pass or persistent auth).

So if you want to stream to Chromecast, you need to ensure that the program is transcoded on recording using the right profile then you end up with an mkv file. And then to play back, do you need user:pass or persistent auth?

Paul M wrote:

So if you want to stream to Chromecast, you need to ensure that the program is transcoded on recording using the right profile then you end up with an mkv file. And then to play back, do you need user:pass or persistent auth?

Yes, I need to ensure recording uses the right recording profile to save as mkv or mp4. I have tried the three variants of links below to send to Chromecast (using the pychromecast example script mentioned earlier). All three work, so I conclude for my setup, that no user:pass or persistent authority is required for recordings.

http://david:****@192.168.1.183:9981/dvrfile/6c7bb5997a33259d53c9681e69afb3d7?profile=chromecast
http://192.168.1.183:9981/dvrfile/e6de721aeca3ecfb9da05cb927c2410d?profile=chromecast
http://192.168.1.183:9981/dvrfile/3ec1ec68c0b55620a49240f3c63c0d04

Thanks 'Paul M' for making the Chromecast useful via 'tvh_epg'. By using the stable TvHeadend 4.2.8.x version on Debian 10 and hacking/editing your python script I was able to bypass the Authentication Token (for live). Further specification of the right stream profiles with videocodec copy 'h264' and audio mp2/ac3 > 'aac' transcoding I was able to make only the 720p50 channels stream to the Chromecast Ultra 'ac3 passthrough could work but haven't tested yet'.

Changing to a interlaced tv channel 1080i25 gives the black screen with a 'darkblue' cast icon on the Chromecast television. Do you or 'David G' have experience with interlaced content using codec copy and are you using NTSC or PAL orientated streams, since the Chromecast doesn't seem to like using anything other than 1080p60 instead of 24p for movies or 25/50?

Hi Walter av, my TV uses 1080p resolution, so I've no experience with 1080i / 24p etc. on TVHeadEnd (in UK using DVB-T PAL). What I do find though is that setting the Video Codec to "Copy codec type" just leaves me with the blue cast icon as you describe. I therefore must specify which Video Codec to use, ie I use "libx264: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10".

BTW, in terms of the Persistent Auth Token, temporarily upgrade to TVHeadEnd 4.3, setup your user and then note the Persistent Auth Token. Downgrade back to 4.2.8, you can now enter this token into the TVH_EPG settings and everything will work without hacking. Easier when Paul M continues to develop TVH_EPG :-). Worked for me anyway, the pain though is that you need to purge uninstall 4.3 and start fresh with 4.2.8.

Hopefully soon they will release a version of TVH 4.3 with transcoding working as it does in 4.2.8.

I'm sorry I have no special knowledge of transcoding with de-interlacing and how the chromecast handles these things.

BTW, another thing I do is to turn my downloaded recordings into a "podcast" so that I can grab programs on a phone or tablet to watch later, I adapted someone else's tool for this
https://github.com/speculatrix/genRSS

Thanks David_G for the Tvheadend 4.3/4.2.8 downgrade trick.

As far as content concerned, only transcoding 'audio' to 'aac' has been done, video is 'Copy codec type' for performance and quality reasons. Googling around about the chromecast capabilities seems that it does de-interlace when it is fed interlaced material in 'h264' and right container and possibly other important flags... mpeg2 is not supported and the ultra does h265.

These settings were succesful for 720p50 streams.

Container:Matroska (mkv) builtin / (MP4 also some suc6)
Resolution (height):1080
Channels:Copy layout
Language:Use original
Source video codec: h264
Video codec: Copy codec type
Video codec preset:ultrafast
Video bitrate (kb/s) (0=auto): 0
Audio codec: libfdk_aac
Audio bitrate (kb/s) (0=auto): 0
Subtitle codec: do not use

Thanks for sharing your settings Walter av, really helpful. I'm learning so much on this journey to get the best from my PI4 / Buster / Pi TV HAT (DVB-T2) setup.

I've now seen the TVHeadEnd log at the bottom of its web GUI and can see my TV card outputs MPEG2VIDEO / AUDIO. I've therefore refined my settings further to try and get the best picture quality without the PI4 stuttering;

Container:Matroska (mkv)/built-in
Resolution (height):0 .....(keep resolution as transmitted)
Channels:Copy layout
Language:Use original
Source video codec: MPEG2VIDEO
Video codec: libx264: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 .....(MPEG2 Video will need converting)
Video codec preset:veryfast: h264 / h265 / qsv(h264) .....(tuned with bitrate for optimum quality / no stutter)
Video bitrate (kb/s) (0=auto): 3500 .....(tuned with video codec preset for optimum quality / no stutter)
Audio codec: libvorbis: libvorbis .....(seems to be less load on the CPU????)
Audio bitrate (kb/s) (0=auto): 0
Subtitle codec: do not use

I believe for my PI4 setup, the best performance would be to use the Video Codec "h264_omx: OpenMAX IL H.264 video encoder" to use the hardware encoding capabilities rather than software as above. Unfortunately the output from this is not quite right, ie, the picture is squashed @ 4:3 ratio on Chromecast. Anyone know if there is a fix for this?

David G, since you use SD PAL which is non-square pixel combinations of 352/704/720x576 you may need to find a way to set the aspect ratio for encoding or force horizontal resolution to stretch 720 to match 1024x576. I'm afraid you have to edit the sourcecode of tvheadend for that or fill in a bug report with missing aspect ratio option or horizontal resolution.

Since the Chromecast doesn't conform to 25fps/50fps or even interlaced no matter what effort you throw at it for re-encoding it will allways lack quality wise. You maybe better of installing VLC/Kodi on a client device, even a raspberry zero with usb ethernet and mpeg2 license can play kodi fine via HDMI-cec remote of your television...

chromecast 50hz option
https://support.google.com/chromecast/answer/6308937?hl=en

Thanks Walter_av, yes, when looking at some channels from the TVHeadEnd log I can see;

2020-02-15 08:14:56.763 transcode: 001F: 1:MPEG2VIDEO 544x576 ==> H264 544x576 (h264_omx) ----- (4MUSIC)
2020-02-15 08:18:32.380 transcode: 0020: 1:MPEG2VIDEO 704x576 ==> H264 704x576 (h264_omx) ----- (BBC ONE)
2020-02-15 08:20:00.663 transcode: 0021: 1:MPEG2VIDEO 720x576 ==> H264 720x576 (h264_omx) ----- (Channel 4)
2020-02-15 08:21:11.520 transcode: 0022: 1:MPEG2VIDEO 720x576 ==> H264 720x576 (h264_omx) ----- (Channel 4+1)
2020-02-15 08:27:19.572 transcode: 0023: 1:MPEG2VIDEO 544x576 ==> H264 544x576 (h264_omx) ----- (Sky News)
2020-02-15 08:29:24.930 transcode: 0024: 1:MPEG2VIDEO 720x576 ==> H264 720x576 (h264_omx) ----- (ITV)

Quite a mix of ratios! I was surprised BBC1 is lower than ITV, buts that's another issue :-)

I'll raise an issues report but for now will stay with Video Codec "libx264: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10" which works correctly but drives the PI4 really hard.

Update about Chromecast 50hz/50fps, still have to test:
https://support.google.com/chromecast/answer/6308937?hl=en

It seems possible to force it via Chromecast settings, this is recomended for any broadcast originated content with a webstreaming platform like BBC or tvheadend in PAL region countries. However I guess Youtube with alot of 23,97/24/29,97/30/59,98/60 will look less optimal on this 50hz mode.

I remember switching this 50Hz HDMI Mode on when I first setup my Chromecast(2) a couple of years ago. I must be honest, I cannot tell much difference and have cast from many apps now.

Hi Paul_M, I believe I have found a bug with the m3u files generated from a Recording link (non-Chromecast), ie line 868 should be;

p_uuid,

instead of

p_uri,

Without this change, my m3u files contained Python error text (name 'p_uri' is not defined) for recordings.

I wonder if the newly released Cast Connect can be integrated.

Tutorial video including code samples
https://www.youtube.com/watch?v=fc5IUJtVpjs

A quick update.

Thanks to all the work put in by Paul M, I've continued to benefit from TVH EPG and the ability to Chromecast over the last year :-)

Last week I needed to build another SD card for my RPI/TVH EPG setup and everything worked again until I got to Chromecast, which would not find any device and produced an error as attached. Luckily I had a backup of my old card so I copied over the original pychromecast directory and it started to work again, ie, find my Chromecast device without any errors. By swapping between the two pychromecast directories I now have, I've determined that the latest version available from repo https://github.com/home-assistant-libs/pychromecast produces this error.

I've checked the dependencies and directory permissions for these two pychromecast directories and they look correct. So if anyone else runs into this problem, I would suggest trying to get an older copy of pychromecast ;-)