Hauke’s Projects

Playin' around with Electronics and Computers

Le Potato Media Center & German IPTV Re-Revisited

Documentation, Le Potato, Media Center, Raspberry Pi, Software, Tutorial, , , , , , , , , , , , , , , , , 23 Comments on 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

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:

Add network
Add network from the configuration tab of tvheadend
IPTV automatic network
Select “IPTV automatic network”
Name the network
Give it a name

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:

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:

Add mux
Add a mux

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

Mux details
Configure the mux – add “?dw=XX” – and give it a name (Service name is optional)

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.

Map service
Mapping services

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

Map config
Configure the mapping

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:

DVBT network
Add a DVB-T network
DVB network setup
Name the network and select predefined muxes matching your location

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

Assign Network to Tuner
Assign the network to your tuner (and make sure the tuner is enabled)

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:

Select and Edit
Select all DVB-T2 muxes and click on Edit
Delivery System Selection
Select DVB-T2 as delivery system (don’t forget to set the tick mark in front of the property!)
Force Scan
Force a re-scan of the network

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

Select DVBT2 services
Select relevant DVB-T2 services and select Edit
Set Priority
Set priority (don’t forget the tick mark in front of the priority field)

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:

IPTV Channel Change Step 1
Select IPTV channels corresponding to DVB-T2 station and Edit
Channel Change
Select the accoridng DVB-T2 channel (unselect any other channel)

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:

EPG Grabber Config
Changing the EPG grabber schedule

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

23 thoughts on “Le Potato Media Center & German IPTV Re-Revisited”

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

    Reply

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

      Reply

  2. 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 ! ??

    Reply

  3. 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 !

    Reply

    1. 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:

      • If the dumb ezcast device is attached to a TV, I’d see if the TV supports CEC, i.e. that the TV remote signals are forwarded to the device via HDMI. This is common nowadays. The ezcast-device than will act on the TV remote’s signals. If it streams DLNA, then DLNA supports play controls, i.e. the CEC remote commands can be translated by the ezcast device to control the DLNA session.
      • If the ezcast device just does miracast, i.e. mirrors the display of a smartphone, ezcast cannot control the smartphone AFAIK. So in this case you need to control the media via your smartphone, which I think is not a problem, since you have it in your hands anyhow. I’d even say it’s the natural way to do it 🙂
      • DLNA servers can be controlled from multiple devices simutaneously AFAIK, so you may use the CEC signals as described above, or you may connect via your smartphone to the DLNA and send controls from there, even if the stream was started on a different device. However, I am no DLNA expert, I may be wrong here.
      • Many devices nowadays offer web interfaces for controling playback. Kodi e.g. has such a webinterface. In my opinion, this is a good way to go: You usually have WiFi in your home anywhere, and your smartphone has a web browser, so this is your remote. If I were you, I’d think more in that direction

      Hope this helped.

      Hauke

      Reply

  4. 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 ??

    Reply

    1. 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:

      • Would still go for a web interface. Make the dumb device controllable over a web interface, create browser or app that displays the devices in individual tabs, and use a smartphone or tablet as central remote.
      • Alternatively, deploy an IR receiver, use a microcontroller or a raspberry or even just a few transistors to multiply the IR signal and transfer it via shielded two wire cable to the target devices (I think this is one of your ideas also). If these have GPIO input, plug it there and use lirc on the GPIO, or for “closed” devices with an IR receiver put an IR emitter in front of the receiver, controlled via the two wire cable. Means to deploy a lot of cable worst case, and may be prone to double received commands. However, if a Rapberry or microcontroller are used, you may put some intelligance in it. But not without (minimum) programming abilities…
      • The USB suggestion you made (if I understand it correctly): Of course you can send simulated keystrokes to the devices, but this certainly would require some level of programming, since you need to handle the protocols… Workaround might be to use the keyboard controller of an USB keyboard and simulate the keystrokes via GPIO attached to the key switch inputs of the controller. Programming skills then would go down to simple GPIO understanding.

      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:

      • With DLNA I guess there is already the possibility to control the playback for other devices by e.g. a web interface. You might need a raspberry with a DLNA client, attach the IR remote to this client softwarewise, and you should be done.
      • tvheadend is more difficult. It has a webinterface, but a) it’s not user freindly and b) it does not offer all functionality you look for. You need to look into the tvheadend documentation how to send API requests to tvheadend to control the stream on behalf of others – not sure if this is possible at all.
      • Many seemingly dumb devices are not nearly as dumb as they claim. If the dumb device sports an USB port, its worth to try and attach e.g. a bluetoothb receiver or a wireless keayboard dongle to it. In surprisingly many cases this just works, and you can use bluetooth devices or keyboards to remote control the dumb device. The reason is that these dumb devices usually run some kind of Linux or Android, which has drivers for many standard hardware in the kernel and thus many such devices work out of the box.

      I guess utter confusion is now achieved 🙂

      Reply

  5. 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.???

     

     

     

    Reply

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

      Reply

  6. 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 !??

    Reply

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

      Reply

  7. 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 !??

    Reply

    1. 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!

      Reply

  8. 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 !

    Reply

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

    Reply

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

      Reply

  13. 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 ???

    Reply
  14. Pingback: What are the best Raspberry Pi alternatives? Everything you need to know about Pi rivals - TECH INSPIRED NEWS
  15. Pingback: What are the best Raspberry Pi alternatives? Everything you need to know about Pi rivals – Talk Data

Leave a Reply to Shippy Cancel reply

Your email address will not be published. Required fields are marked *

Scroll to top