How to Chromecast?

Gabs Man · 2016-07-29T14:17:23+00:00

I have a Chromecast 2. I also have a Media server running OpenMediaVault and TVHeadEnd with a dual tuner. I think it's great, works really well I have been u...

David G

Umm, in terms of "json_str = json.loads(jsonString, strict=False)", where would you suggest to add this in the PY code please?

Paul M

Hi,

yes, there's channels which have no icon. And some channels with a +1 do have icons and some don't, so there's a hack to always using the non +1 icon. It's all a bit hacky really. If I knew that tvh_epg.py was always going to run on the same server where it can find the picons then it could peak into the file system and have a better guess.

thanks for the comments about pip modules, I've added comments to the chromecast.md about it, so a fresh git pull will grab that. there's no functional change.

I'll work out where to put the updated json.loads and publish an update.

thanks for your patience and persistence.

I've forgotten how to make a deb package, I should remind myself then I can do that and make the whole process simpler.

thanks

David G

Thanks for the update Paul. I've updated to the latest PY file, not noticed any difference from my side.

I've now setup the missing logos as you described - job done :-)

In terms of the EPG tab error, I've noticed that at some times during the day, it will actually display all the channels, then at other times, it seems to get stuck on a particular channel for awhile. I'm wondering therefore if there is something in the DVB-T EPG data that's tripping up the code, which is fine though for DVB-S?

Let me know if you want me to do some sort of logging to help work out what's going on?

Paul M

I've not had an problems with the page stalling other than rendering the very large table with many images if I'm using a slower device. On my laptop it's just fine. Is your R-Pi beginning to run a little low on RAM to run TVH and the web ui and anything else?

David G

Sorry Paul, my post was misleading. I was trying to clarify that the point when I get the "JSONDecodeError: Invalid control character" appears on a particular channel and will continue, presumably until the epg data moves along to the next time slot later in the day.

Maybe its down to working out how to implement "json_str = json.loads(jsonString, strict=False" but I dont know where to start ;-)

Paul M

Hi David G,

I've a little more free time now, had some time consuming deadline things to attend to.

I added the quick fix for the non-strict json.loading from the json sent by the TVH server.

If you still get the problem, please uncomment line 341 and send me the raw dump text before it gets to json conversion, code snippet at end

The the epg page will display the raw dump from the server, please copy the raw dump into pastebin or something and post the URL here.

thanks for your patience. hopefully we can crack this problem so others will find it easier to use.

regards

Paul

#print('<pre>Extreme Debug!\n\n%s\n<pre>' % (ts_text,))

David G

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!

Paul M

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.

David G

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).

Paul M

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.

David G

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.

Paul M

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!

David G

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:password@192.168.1.183: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!

David G

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

Paul M

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:pass@tvh.example.com: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

David G

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.

David G

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?

Paul M

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?

David G

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

Walter av

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?

« Previous Page Next Page »