Le Potato Media Center & German IPTV Re-Revisited
The comment by Argus Nymus on my Media Center for German IPTV post made it clear that my approach with playlist filtering via web proxy was way too overengineered. For several reasons I needed to rebuild my media center anyhow, so it was time to simplify my approch, which I describe in some detail here.
To skip my blah blah on Le Potato, you may go directly to
- Setting up tvheadend with German IPTV (the simple way)
- Using IPTV mixed with DVB-T2 (including how to set up DVB-T2 channels)
- Using HbbTV services’ EPG
Le Potato – State Of Affairs March 2019
A bit more than one year after Le Potato hit the market there is still no feature-complete open source mainline kernel available. The progress on it is considerable (see downloads section on the product page), and not too much is missing, but especially the multimedia features, which of course are crucial for a media center, are still incomplete. For this reason, the two Kodi projects that officially support Le Potato, namely LibreElec and CoreElec, still use the old 3.14 kernel by amlogic, containing some closed source, and which – according to the open source developers – is crappily done. I regularly try out new incarnations of the two projects. CoreElec is definitely the one that better supports Le Potato, while LibreElec still has a few bugs.
Honestly, I would not worry too much about the old, closed source kernel – I do not really care. But I got myself a Hauppauge WinTV dualHD USB TV receiver, and suddenly the kernel was no longer to be ignored. The receiver on first glance seems to work with the old kernel when using the CrazyCat TBS driver package, but it’s just not good enough. Using one tuner, it’s OK, but every few minutes there is a frame dropped, and that’s already more annoying I’d have thought. As soon as tuner #2 comes into play, things get unbearable. That dramatically changes as soon as you use kernel 4.11 and above: The device is natively supported and works rock solid on both tuners (N.b.: LinuxTV claims full support available only with kernel 4.17 and above).
After the desaster with my Smart TV I needed a working TV better sooner than later, and so my current solution is to have a Raspberry Pi with kernel 4.19 running in parallel with Le Potato. The Raspberry Pi now has the tvheadend server role, but has no H.265 capable GPU, which is why Le Potato remains my media center device, playing the HEVC content pulled from the Raspberry. This only requires the tvheadend PVR frontend on Le Potato to be configured to point to the Raspberry Pi as tvheadend server. That works very nice and stable, but I still cannot wait to have the new kernel on Le Potato: I hate to waste another 5 W of energy with the otherwise unneeded Raspberry.
As a closing remark here: You can very well see how much the community is at least of equal importance for a SBC as the features it offers in itself. Raspberry Pi falls back in feature set more and more, but OS and software wise, it outclasses the Le Potato by far.
Setting Up tvheadend With German IPTV – The Simple Way
Recap: The 30 Minutes Problem
As in my previous setup, the goal is to use the live streams that the public service TV stations provide via the Akamai network. The tricky part is that the streams are set up by the TV providers to cover 30 minutes of stream, which is to allow skipping backward via their web interface. Using the playlists unaltered would lead to a not-so-live TV experience lagging behind half an hour. Argus Nymus pointed me to the GET parameter “dw” that you may add to the Akamai URLs, which allows you to set the time span covered by the stream in seconds – and that does the trick! Thanks again Argus Nymus! So lets…
Configure tvheadend For IPTV
I’ll skip any basic setup stuff regarding installing tvheadend – this is covered extensively by many tutorials on the web. So I assume that you’ve successfully set up and configured the tvheadend base.
The general concept of tvheadend is: You have a channel, to which one or more services are mapped, which are derived from muxes (short for “multiplexers”) that are part of (broadcasting) networks. So in the following I create an IPTV network, build the muxes from the live TV playlists, which automatically results in the creation of services, which I map to channels then. All is done by using the tvheadend web interface accessible via http://<your device IP or name>:9981.
Create IPTV Network
The German IPTV playlists work with an “IPTV automatic network”, which you may name as you like:



Create Muxes From IPTV Playlists
The playlists for the German public TV are available from many sources – one very good is this one (search for “!<Your TV station> #Livestream” – thanks again Argus Nymus!). The URLs look like this:
https://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/master.m3u8
If you download them and view them in a text editor, you get something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
#EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=184000,RESOLUTION=320x180,CODECS="avc1.66.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_184_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=184000,RESOLUTION=320x180,CODECS="avc1.66.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_184_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=320000,RESOLUTION=480x270,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_320_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=320000,RESOLUTION=480x270,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_320_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=608000,RESOLUTION=512x288,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_608_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=608000,RESOLUTION=512x288,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_608_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1216000,RESOLUTION=640x360,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_1216_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1216000,RESOLUTION=640x360,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_1216_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1992000,RESOLUTION=960x540,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_1992_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1992000,RESOLUTION=960x540,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_1992_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2691000,RESOLUTION=960x540,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_2692_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2691000,RESOLUTION=960x540,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_2692_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3776000,RESOLUTION=1280x720,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_3776_av-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3776000,RESOLUTION=1280x720,CODECS="avc1.77.30, mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_3776_av-b.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=56000,CODECS="mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_184_a-p.m3u8?sd=10&rebase=on #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=56000,CODECS="mp4a.40.2" http://wdrfsgeo-lh.akamaihd.net/i/wdrfs_geogeblockt@530016/index_184_a-b.m3u8?sd=10&rebase=on |
I am only interested in the two highest resolution streams, which I highlighted in the list above. For those two URLs I create a mux each:

Now in the URL-field you paste the desired URL from the m3u8 playlist above, and add &dw=XX to it at the end, where XX is the number of seconds you’d like to have the stream to cover. 20 sec is enough for me, having the TV as live as possible (of course, IPTV is always a bit behind anyhow, but we’re talking about less than a minute here).

After hitting “+ Create” the mux will be created, and within the next few seconds tvheadend will scan it. If everything was done right, a new service will be created.
Make sure that you name the muxes for the same TV stations in the same way – you’ll see why in the next step.
Alternatively, you could directly paste the m3u8 URL from the top of this step, add the &dw=XX there. You’d then get a service for each playlist entry – the task then would be to pick only the desired services. Using the GET parameter b you could filter by bitrate, which may save you the trouble, but having the stability issues from my first approach in mind, I did not bother. In case you try it, please leave a comment below!
Map Services To Channel
The service now needs to be mapped to a channel. I’d do this step only after I have created all muxes, since the mapping procedure can digest many services at once (just select all of them before clicking “Map selected services” – see below) and will create the channels according to the mux names. Hence the recommendation to pick the same mux names for the same TV stations.

Select the “Merge same name” tick mark. tvheadend will then create new channels as needed.

And that’s it basically. The channels can now be consumed by the tvheadend PVR frontend in Kodi.
Using IPTV Mixed With DVB-T2
My DVB-T2 device has two tuners, so I can record and watch independent channels simultaneously. Still, I’ve had situations where I recorded two channels, and still wanted to watch TV. Fortunately, you can mix different services into one channel, and assigning priorities, you can define which source to try first, and have others as fallback. So below I configure tvheadend to first try DVB-T2, and then IPTV for any channel available from both sources.
Setting Up DVB-T2 Reception
There are many DVB-T2 tutorials, but following them by the letter didn’t work out for me, because they omit one step necessary at least with my WinTV receiver. So here are all steps I did:


The following step must be done for any DVB-T2 tuner you have in the list on the left:

The next step is the one missing in all tutorials I checked on the web. I needed to change the delivery system to DVB-T2, since it is set to the “old” DVB-T by default:



Now you need a bit of patience while tvheadend scans all frequencies. You now should see services turning up, and from here it’s like in the IPTV-section: select the services and map them to channels.
Mixing IPTV And DVB-T2
Assign Higher Priority To DVB-T2 Sources
To have DVB-T2 to be the service first used, and IPTV only as fallback, the priority of the DVB-T2 services must be higher than that of the IPTV services. To achieve this, select all used DVB-T2 services (in the screenshot you’ll see assigned priorities already – ignore; default is 0):


I chose priority 2 for no particular reason – it just needs to be higher than that of the IPTV services, which default to 0.
Map IPTV Services To DVB-T2 Channels
In order to have the IPTV as fallback for a given channel, select all matching IPTV services and select edit:


Do not forget to set the tick mark in front of the channel field.
I’d recommend to map the IPTV services to the DVB-T2 channels rather than vice versa. This ensures that the channel name matches the over the air EPG grabber associated with the DVB-T2 station. Of course you can configure EPG manually later, but why bother?
And that’s it basically. tvheadend now will try DVB-T2 first whenever you tune to a given channel, and will use IPTV if all DVB-T2 tuners are already booked.
Using HbbTV Services’ EPG For Pure IPTV Channels
Currently Kodi does not support HbbTV, the relatively new hybrid TV standard. I understand that tvheadend does, but Kodi has no plugin I know of that consumes the data provided. Reading in the forums it even seems that the current Kodi developers are kind of opposed to adopting this standard, which is a pity IMHO. Until it broke down, my smart TV provided HbbTV to me, and I find the added value useful. Main roadblock seems to be that you need a web browser/http rendering client, and that does not yet exist for Kodi, although often asked for.
Anyhow, at least in Germany among the HbbTV signals are a few TV stations that are not aired directly, but as HbbTV-“link” to an IPTV stream. While I cannot consume them directly in Kodi, there still comes along some EPG information (as it seems only the current and the upcoming show). And since I have not found a legal EPG source on the internet yet and do not want to use the dodgy ones, I want to add the EPG information from HbbTV to the IPTV channels wherever there’s a match.
To achieve this, I used the exact same approach as above, with the only exception that this time I assign a priority of -10 to the DVB-T2 signal, making IPTV the default. Keep in mind that the channel name should match the DVB-T2 HbbTV channel name if you do not want to manually configure EPG mappings.
Since only the current and next TV show comes with the HbbTV EPG, I changed the over-the-air EPG grabber schedule to run every hour instead of twice a day as the default would be:

That’s it.
Btw.: If you know of a legal source for tvheadend EPGs for German TV, or you know a working HbbTV implementation for Kodi, please write a comment below!
Update: I’ve created my own legal EPG scraper for some German TV
I have read with interest your previous related article too, with DIY IR receiver. ??
Here is my issue:
1. Does TVheadend support IR remote control ( via Lirc or other)?
Here we are assuming that the IR signal can be carried to the TVheadend server via a serial port, from IR receiver.
2. If yes will TVheadend support channel switching via an ordinary TV remote control while TVheadend streams to a DLNA device?
E.g., to a $10 ezcast/Miracast WiFi (or USB) device ( See AliExpress.com for these very popular devices under “TV dongles” or “ezcast”.)
3. If still yes, how about TVheadend streaming via DLNA to multiple dongles each with an associated IR remote?
Here we will likely need multiple IR signals going to the TVheadend server over multiple serial ports, or on an Ethernet-USB port multiplexed in some port or IP/MAC addressable way.
Hi Shippy,
tvheadend in itself does not support a remote control and IMHO never will, since its concept is not to be a frontend. The frontend (e.g. the tvheadend HTS client plugin in Kodi) is responsible for handling user input like an IR control or a keyboard. You need to look for IR remote support on the media player you are using. Kodi e.g. supports loads of remotes, IR, CEC, Joysticks, … Also, if you have a TV set that does DLNA, the TV set will handle the remote.
tvheadend itself is a media server (as opposed to the frontend/client) wich allows devices to subscribe for one or more media streams. So if you switch on TV channel A on your Kodi, it under the hood will subscribe to the tvheadend stream for channel A and tvheadend will deliver it. If you than switch to channel B, the frontend will cancel the subscription to A and create a new subscription for B.
tvheadend can be used from several clients simultaneously, so e.g. Kodi may subscribe to channel A while the DLNA receiver is on channel B (assumed that the receiver supports it), so the remote attached to Kodi can be used to switch channels there and the remote of the DLNA device may also be used to switch channels there. In that sense, tvheadend supports any number of remotes 🙂
Hope that was not confusing. Long story short: Pick a suitable frontend that can subscribe to tvheadend, and find a remote that works well with that frontend.
Cheers
Hauke
Hauke,
Thanks for a very clear and quick reply.
Essentially the client ( media player) sends control requests to server which replies appropriately, as in client-server model. The IR receiver talks directly to client since it is physically in the same place (people watching media player/ smart TV and clicking on RC device.)
But then control can be separated from server and client.
Made me think a bit more 😆
1. FYI, this (and #2) is what motivated me, re: IR control by Jafath blog listed (no answer from him- likely a G+ sign-in problem !)
https://tvheadend.org/boards/4/topics/29273?r=29274
2. You might have come across this interesting “live streaming” DLNA plug that works on Openwrt:
http://xupnpd.org
This talks mostly about streaming to a smart TV, but I was thinking: is it possible to stream to a display adapter like the ezcast Wifi HDMI TV dongle I mentioned above? The dongle itself is a closed Linux distro that supports own ezcast + AirPlay + Miracast + DLNA:
https://www.ezcast.com
So the question: Can one write a script connecting the IR receiver output and the Server (running on Server) to change channels? It’s conceptually not difficult, but theory and practice are not the same, as the great philosopher Yogi Berra pointed out ! ??
A bit more:
In my scenario, the (cheap) display adapter is a “dumb” client that only is receiving a media stream over DLNA it can convert to HDMI format for (regular) TV display. Perhaps a few DLNA handshake protocol bits going back to server.
For example, the ezcast dongle works with a smartphone that can stream YouTube live to it, and connects via WiFi Direct ( p2p) or through router if you want public IP access. The smartphone is thus both server and remote control.
The media server actually receives its commands from the ubiquitous IR (or 2.4G wireless or Bluetooth) remote control that acts as a pseudo client. Lirc likely has partial scripts to handle multiple incoming RC requests from various TV set display adapters over WiFi or USB-Ethernet ports requiring some addressable way, e.g. usb port IDs or device MAC/IPs.
Thus some additional script ( on server) might be needed as a bridge between Lirc on server and the pseudo client ( simple RC device ) that can only send keystrokes from the human user.
If possible, this would be a very effective, convenient and cheap system !
Unluckily I am not a programmer, just a product manager with a tech degree looking for efficient design.
In summary, I believe, we need a short bridge script to Lirc ( akin to NAT, maybe a Linux module available) running on server such that:
1. PortID = physical USB/eth port ID, or virtual port,
Keystrokes ( from RC device, human user)= new stream/new action to the associated display adapter.
Keystrokes transmitted via WiFi/wired from IR receivers close to RC device (transmitter) over a home network/ LAN.
2. Server receives { Keystrokes: portID: Device ID} stream from RC device,
3. Server sends back new stream/action to {new stream: PortID: DeviceID} after canceling current stream/action.
Note: DeviceID actually represents a mapping between RC device ID and associated display adapter ID, such that server receives receives from RC device and streams to display adapter !
Hi Shippy,
I am not 100% sure if I understand what you want to achieve, so my remarks may be off the mark. But some input here:
Hope this helped.
Hauke
Hauke,
Appreciate your quick reply.
Well I am just looking for a very simple, cheap system that has a “dumb” TV ( no CEC or communication with attached HDMI ezcast WiFi dongle.) The TV remote has thus nothing to do with the dongle or control of DLNA stream to dongle from media server. The dongle is independently receiving the media stream from the server (in the default case this is the Android phone.)
So what I am looking for is a 2nd independent RC remote control ( a regular TV remote model) that the user ( TV watcher) can employ to control the DLNA stream to this ezcast dongle ( displayed on TV set) from a media server like TVheadend (not smartphone.)
To me it seems that the user should be able to press (Lirc) standard keys on this “dongle” RC so these keystrokes are received via IR by an IR receiver.
This IR receiver then transmits the digital data over 2-wire cable into a network with, for example, USB ports receiving this data stream.
This is to say that as long as the dongle RC device key commands are received eventually by the media server over the network, the media server should be able to identify the individual RC device and the associated dongle to which the server response ( new stream/action) can be streamed back.
This doesn’t have much to do with DLNA itself, but is a bit unusual design ??
OK, I think I get it now: You want to have a content server (DLNA, tvheadend, whatever…) that is contacted by more than one receiving device (the “dumb” thing). What is displayed on which dumb device should be controlled by a “central” remote, on which I may select individual play control functions for each and every dumb device.
Could think of several ideas:
Thats what quickly comes to my mind.
What still evades me to some point is the benefit. Why would I want to control several media players centrally? My bias would be that the person(s) in front of the media players would want tro control their program themselves, each one needing his or her own remote…
EDIT: reading your comments once again, I think I still misunderstood – Did you mean that the dumb device has no way of being remote controlled and you want to have a seperate remote control device that controls the media source (DLNA, tvheadend…) on behalf of the dumb device? If so again a few ideas:
I guess utter confusion is now achieved 🙂
Hauke,
No confusion at all !?
I am glad I was able to communicate to you -80% of the solution- it is about the last item you highlighted, i.e., “dumb” receiver ( display adapter dongle) that cannot talk to an IR device itself.
Here is an example:
Main parts:
A. TV set with own IR RC (everyone has it.)
B. A WiFi ezcast.com HDMI dongle to attach to TV set. This will receive a DLNA stream from the media server below.
For Anycast M2 MiraScreen miracast TV receive Dongle hdmi adapter WiFi Display Receiver for DLNA for Airplay Support ios android
https://s.click.aliexpress.com/e/bKnKjtC8
Note that the USB Y cable can be detached to expose the micro USB OTG on the dongle itself. This dongle can actually receive the DLNA stream via Wifi or USB.
C. An independent RC + IR receiver with USB plug:
USB Media IR Wireless Mouse Remote Control Controller USB Receiver
https://s.click.aliexpress.com/e/cbufdPws
This IR control system can be inserted in between the dongle Y cable and the dongle (with another Y cable), so that the ezcast dongle can send/receive on the USB cable connection while the IR signals can be sent downstream to the server on the same USB connection.
In fact the dongle USB cable from the dongle/IR receiver need not be a Y cable, the other USB plug being for power: the other end connecting to the media server can be a powered hub supplying the ezcast and the IR receiver.
This powered USB hub can attach other dongle/IR incoming connections, and all such connections then go via hub into the media server box plugged in.
Also note that if the ezcast dongle is receiving the DLNA stream via Wifi, the IR control signals will go through their own USB cable. If the dongle receives the stream via USB, the cable is shared. Thus only one cable is needed in either case.
The bridge script I talked about will need to process these multiple incoming IR signals via, for example, dongle device IDs, so then the server can respond with a new stream outgoing to the correct dongle !
Incoming string to server: { IR signal: USB portID: DeviceID}
Outgoing string from server: {New Stream/Menu: USB portID: DeviceID}
D. The media server box. This could be an old PC running Ubuntu. Or an OpenWrt router.
TVheadend is a candidate for DLNA media player, with LIRC or other Linux package to manage the remote control feature.
So why this? Because this will be a really cheap system, and very flexible.???
I had a quick look on the EZcast devices – it seems indeed to be a closed source product for which no open source implementation is quickly available. However, I’d be surprised if the underlying OS is not something like Linux or Android. So my first try would be with the Y-cable to attach a wireless keyboard and see if this does not allow me to control the device directly. Would also have teh advantage that you can use any available search functions more comfortable. The EZcast product pages mention also that the device can be controlled via an app – so why not use this? I could not find any reference that it supports CEC, which is a pity, because this would be the simplest solution of all. The solution you suggest is feasible, but I’d be surprised if you can do this with ready at hand software. You certainly will have to do some programming/scripting. If I were you, I’d look what the DLNA protocol holds in stock – perhaps this DLNA remote controller script is a good starting point. Combined with LIRC you may get where you want to be. There also are apps for a smartphone to remote control DLNA. In the end it might help to understand DLNA/UPnP better to understand your options – a quick Google search brought me to this page that seems to explain the concepts a bit.
Last remark: I’d heavily mistrust the EZcast device – it is “too cheap to be true” – most likely because they sell usage data collected in the cloud to third parties. I do not like to be spied upon.
Hauke,
Thanks for the engagement !
Yes I certainly would need to get some bridge script developed, unless I can get into the ezcast.
Below are two interesting takes, first from XDA (I read the first page description and the last p12 comments.) Says ezcast ROM can be modded…
https://forum.xda-developers.com/showthread.php?t=2632288
Second an official reply to hacking backdoors:
https://forum.iezvu.com/phpBB3/viewtopic.php?t=375
So do you think ezcast can be modded to work with a regular TV remote control as in my remarks above? Of course it works with phone apps, but I don’t want to use the phone/apps.
I believe that for $10 ezcast is a great device compared to Chromecast and functions better !
So either the original proposal of sending RC keystrokes to the DLNA server, or first to the client ezcast dongle could work.
In either case it is the same physical network with wired and/or WiFi connections. And a script will need be written for either server or client. In the client case, maybe all you need to do is interface with existing DLNA protocol module to just input the RC keystrokes. As you mention, the TVheadend server is not currently setup to receive RC commands.
And yes I rather have a$1 RC control the $10 ezcast client than have a $100+ phone do it !??
OK, if there is a modded ROM, you’re one step closer to success. From the links you provided I understand that it’s indeed Android running on the EZcast device. Perhaps you can even find an apk to support a generic IR receiver? I could not find one quickly, but I only did a very cursory search… Then you’re done rather quickly, since you then can use that receiver to directly control the EZcast device, which I would say is the best approach anyhow. Or you may find an apk for CEC integration if your TV provides CEC. It seems that this page has something in that direction.
Hauke,
I thought it was Linux but you think it is AOSP? Can it be done in 128MB? Which reference did you see for Android?
Sure if its Android, it is easier !??
Seems that I didn’t look properly – I mixed Chromecast and EZcast references… In this PDF security analysis they claim it’s Linux… Interesting paper anyhow, may even help to get into this device…
Good luck! If you find a clever way, be sure to post it somewhere!
I want to correct myself re: same physical network for the WiFi case. In fact if the ezcast can process the RC commands (via DLNA) there is no need for the IR RC wire- it would defeat the purpose of Wifi if a wire is required??
Thus the dongle-RC control is a better idea than the server-RC control.
So now it is a matter of finding the SSH userID/password…then installing a Linux DLNA- RC plugin like LIRC, unless already available !
Hauke,
Will see what I can do…need that SSH login/password. Not explained in the Checkpoint report from July 23, 2015. Apparently in Aug 2015, per XDA post as above, ezcast did upgrade the ROM.
It seems that at least some such devices have a UART interface, which may give you SSH access directly with a root shell – see e.g. this page and the PDF linked there. This page seems to be a good introduction in how to work with UARTs in general, in case you never did this before.
Hauke,
Just great references ! Will look deeper into them. Meanwhile posted my question on the GitHub:
https://github.com/c3c/miracast/issues/1#issuecomment-480651476
??
By the way, just found a UART hack, and apparently the root password is listed?
https://github.com/gipi/teardown/blob/master/MiraScreen/README.md
So do you think LIRC could be installed? This report seems to say you can’t install applications…
Many UART interfaces let you in passwordless to a root shell (see e.g. this example from my TV set). Installing software is a different matter. I’ve near to none experience with embedded Linux, so here you’re on your own, but the link you posted seems a very good starting point! If I understand correctly, it is exactly the chip the EZcast devices use. Perhaps you should contact the author of the Github page and ask for guidance there.
Hauke,
Nice article of yours, posted request as you suggested ?
https://github.com/gipi/teardown/issues/2
Hauke,
The gipi guy above says that he meant officially applications are not allowed. But shell access means you might be able to…see above link.
Hopefully the root password works on most models since ordering doesn’t always deliver the exact same model.
Anyway it has been a good intellectual exercise ???