While exploring how to extend the quick live play code. Here in the Northeast we had many power outages this week, so getting a client to be able to work without the internet was important. Power is easier to be had than internet connectivity. All the current clients need to have internet connectivity which we often don’t have. This was where I got to the last time I posted:
But I found out why the Tablo app on Samsung can’t jump around the live TV stream, the Tablo generates m3u8 playlists, and I found where we all got stuck:
The jumpForward(), jumpBackward(), and seekTo() methods of the AVPlay API, which are related to live seeking, have limited functionality in live streaming. If you want to use live seek, the streaming server must maintain past and future segments. The seekable range is limited to the segments maintained on the server. The following table lists the streaming engines that support live seek.
Which makes me want to carry on with the work to write what is essentially a DNLA proxy for the Tablo, this would make it work on all DNLA clients. It would be so much easier if the Tablo was able to do this natively rather than have another layer in between that basically just acts as a proxy and would double the bandwidth for the transcode. Team @TabloTV have mentioned DNLA before, but it would be an easier fix to have minidnla running right on the Tablo… also getting rid of the “need internet” would help for people off grid.
I like the concept of “lightweight DLNA.” I built a media server from a Raspberry PI using Raspbian (thin Linux variant) and MiniDLNA. With TVheadend as a TV interface for a USB tuner plugged into the RPi. The whole bundle takes only about 10% of 1 GB memory and runs 24 x 7 without stop (no crashes). It serves my 3 Rokus, 2 Kodi boxes, 1 iPad, 1 Nexus 7 and 2 Android cellphones - thanks DLNA. Total cost? $35. Power consumption cost? Practically nil. Possible replacement cost? Another RPi
You’ll have to keep us apprised of your CUDA programming effort since I’ve only discovered last year the great value of GPU programming as an adjunct to mainline CPU coding. BTW I’ve been following FPGA programming as well as an adjunct to a main processor. Both Microsoft (Azure) and Amazon (AWS) have added to their Cloud environments auxiliary tools such as GPU and FPGA resources that can be dynamically instantiated. I’m wondering how either of these may impact processing of television signals in the future by offloading such work from a main processor.
I basically use TVheadend to record programs (as another DVR resource next to my Tablo) and MiniDLNA to stream the recorded programs (behaves very well with Roku and Kodi). So my Roku sees both the Tablo and RPi as TV sources.
TVheadend uses the 24 hour guide transmitted by the stations but has the option of using XMLTV to supply a two week guide accumulated from a variety of free and legal sources (something I intend to implement later).
BTW I’ve found the Tablo app for Kodi to be more responsive with better picture quality than the Roku. The Kodi box is an Amlogic S912 with hardware video acceleration and the Tablo image appears just a little more fluid and sharper here.
