LinuxMCE Forums
General => Developers => Topic started by: kyfalcon on March 12, 2012, 07:58:44 pm
-
Has anybody with working knowledge of LMCE and mythTV had a chance to look at this new API? Will it possibly make Myth more of a stable partner for MCE? Thom, I know you share my current disdain for Myth as far as stability. Could this new API allow us to see something of an improvement?
Kevin
-
lotsa looks, no replies... lol
I will give her a go tonight presuming all is stable with the other stuff I am doing.
-
Let me know what you find. I have been looking at the code a bit. And would be willing to help the best I can.
-
I don't know why I would think my stuff would be stable enough to try and shoehorn something that big in... lol.
I give no time frame on this.
-
Let me know how I can help!
-
From what I gather from this API, we have 2 courses of action. 1) rewrite MythTV player to use the http calls with the new frontend API. or 2) create our own frontend and use the other API's which to me would be maybe more work but in the end a much better approch, since this could integrate into the new QOrbiter.
The backend of myth works just fine currently, it is the communication with the frontend that is flaky as hell. If this new API allows us manipulate myth within an orbiter screen of our design then this whole system becomes much more efficient and fluid.
-
qOrbiter won't talk to MythTV direct. Everything else would be a discourse from the architecture. qOrbiter talks to dcerouter which talks to what ever PVR is installed.
mythtv-player and mythtv-plugin won't be changed to talk to MythTV 0.25 for LinuxMCE 1004.
-
posde, I understand where you are coming from. My point being that from what I could determine from looking at the code( and I could be very wrong) currently MythTV Player communicates through a socket with mythfrontend to watch, change channels etc. The mythfrontend client communication is fairly unstable. This new api would allow an lmce md to communicate directly with the mythbackend even if it is through the DCEROUTER. We could basically eliminate the mythtv frontend altogether in favor of an lmce frontend.
-
I'm all for anything that would improve user experience. What would essentially happen would be a new MythTV Player would be written to interface with the 0.25 API.
As for a new front end, The new MythTV Player would perform this function.
We also need to investigate VDR's viability as a replacement for MythTV as well.
-Thom
-
Thom from reading the API it looks like we would be able to eliminate the need for myth frontend all together and our MythTVPlayer would get the stream straight from the mythbackend. Under this approach we would need to handle the UI for the guide and programming etc. I'm curious how this is handled currently in VDR as it is my understanding that VDR is stricly a backend and LMCE handles the UI frontend.
Kevin
-
we use a VDR device (aka VDR player), you can look at its source code, it essentially uses vdr-sxfe, which is a modified xine.
This provides the minimal UI, which Orbiter of course, lays on top of. Posde can explain this a lot better.
-Thom
-
VDR integration and MythTV integration are identical. Both are using dedicated players.
The advantage of the VDR integration is that the frontend gets out of its way, whereas the MythTV frontends jumps at you. The advantage of the MythTV integration is that you are able to select recordings from the videos part of LinuxMCE.
-
Posde my understanding of the MythTV .25 is that it allows the MythTV to get out of the way also. The big issue I see is the guide data and setting up recordings, how is this data presented to the orbiter for VDR, I would assume we could mimic that code.
-
the Plugins are supposed to handle this code.
For an example, look at the data grid generators in MythTV PlugIn, there are a few of them in there. These datagrids are generated, and sent over via the Datagrid Plugin to Orbiter when needed (when a DataGrid object is on a designobj)
-Thom
-
Thom, I though the guide data that we currently see for MythTV was actually just the guide part of the mythfrontend and basically lmce just passes keystrokes to the frontend.
By the way I appreciate the discussion, it helps me learn and understand this more, which means I might be able to contribute more
-
...
There is also an orbiter exposed guide, which you can see IF you have a tablet running Orbiter, OR you have a gyro remote and press the media key, OR you press F6 on the keyboard, and select up/down.
-Thom
-
See, I learn something new everyday. I will have to take a look at that tonight.
Thx
-
Folks,
Just as a point of interest, Robert McNamara of the Torc project (torcdvr.com - a fork of MythTV) has submitted for App store approval an iOS Universal app which leverages the 0.25 Services API to create a remote control and stream/viewing application for iPads/iPhones/iPods. It's a native iOS app, and all it's functionality is via the Services API.
http://www.gossamer-threads.com/lists/mythtv/users/513724#513724
http://www.youtube.com/watch?v=uxQDLTSucxM
http://www.youtube.com/watch?v=uGoU90bdUC8
That could bode well for a stable interface for LMCE into Myth for all aspects of control.
Just thought I'd pass that along...
/Mike
-
That's pretty effing nice!
-
Hi all,
Not sure if this goes in to this thread or not...
What is the problem with Myth? Or perhaps a bit sharper: What's the problem with Myth under LMCE? since it appears that many (and many, and many) users are having a good and hassle free experience with dedicated Myth distros.
Is it the backend? Then I am going towards a dedicated myth backend, that the LMCE-Myth master backend can utilize (believe we are keeping to 0.23.1? Rigth?). Is it the frontend, then moving away from the current setup seems to be a very strong suggestion. Is it as stated below the communication between front and beckends, then a rethink would definitely be on top of the list!
Personally I have never got to a usable LMCE solution, solely because of the poor TV experience - and I am not limiting myself to Myth, since I **WANT** what LMCE potentially can deliver. So for the moment I am booting up the servers (physical and virtual) and MDs every now and then, see where it brings me.. But I feel there is still some way until I would consider taking the plunge and go "all-in" on LMCE..
I can easily follow why some (Thom and others) are having a quite hateful relation to Myth, but feature comparison wise are we not limiting ourselves too much by going the VDR way? For me comm-flagging and the advanced scheduling are VERY big Myth plusses. I would like (before offering myself to doing actual developing) to have the input from some of you with more experience with how TV CAN work. If Myth was stable, which platform would you choose, Myth or VDR????
I am all for (since 0.25 is tied with 12.04 already) going down that route, everything else seems to be like putting a Mickey Mouse patch on a leg torn of...
-Tony
posde, I understand where you are coming from. My point being that from what I could determine from looking at the code( and I could be very wrong) currently MythTV Player communicates through a socket with mythfrontend to watch, change channels etc. The mythfrontend client communication is fairly unstable. This new api would allow an lmce md to communicate directly with the mythbackend even if it is through the DCEROUTER. We could basically eliminate the mythtv frontend altogether in favor of an lmce frontend.
-
Comm flagging and scheduling are working nicely using plugins for VDR for me.
-
I'm not using LMCE in production right now; I'm testing it and playing with some proof-of-concept ideas that I'll throw forward for inclusion when I get them usable.
I am running a production MythTV 0.24 environment, with a master back-end, a slave back-end/front-end, and three other front-ends. The Slave and the front-ends all run MiniMyth. I'll likely be upgrading them to 0.25 when Debian-Multimedia has it in stable. I've run Myth since 0.21 (with Freevo for three years before that), and it's been generally stable and the WAF/KAF has been high. The Myth stats page shows 4050 episodes recorded over the last three years, with a mixture of Analog cable, Digital OTA, and a Digital cable box (6 tuners in total).
Myth and VDR both exist in LMCE now for a reason. Some of those reasons may be technical, some may be historical. Out of curiosity, I'd posted a poll asking what people were using. 76% of the people who had responded indicated they were using Myth. I believe Dianemo has moved to using primarily MythTV (Dianemo users are welcome to correct me if I'm mistaken). It would be interesting to see a technical comparison between the two, and see where the strengths and weaknesses are between the two, and how well each can/do integrate into the LMCE system. That kind of capability and requirements analysis could help drive decisions around architecture and features. It doesn't necessarily mean that the less capable is removed; if the devs wish to support both, it could be used as a tool to drive innovation to address the deficiencies. It could also determine where to best spend limited amounts of developer time if there's a huge gap in capabilities.
As best as I can see, VDR basically supports DVB and MPEG encoder cards, plus some European IPTV providers (again, correct me if I'm wrong). MythTV supports those plus the HDHomeRun series, the Ceton cards, ATSC tuner cards, and the HDPVR. So, where a user lives, what their input sources are, and what hardware they have access to will drive the choice of VDR vs MythTV. At the very least, quantifying some of that could be useful in setting AVwizard defaults, and building documentation in the Wiki.
My $0.02 worth before HST...
/Mike
-
I have stated this many times in the past,
There are a few reasons that I am looking at either using VDR or writing a new PVR from scratch for LinuxMCE,
the biggest is, the incredibly superfluous UI that does not mesh with LinuxMCE's Orbiter at all. There is a huge amount of overlap. Now, you all being geeks, I can understand why you would say, "so what?" ... I CARE about it, and MythTV literally looks like we're hanging an UGLY side car off the system. I want it gone.
The other is that MythTV's performance is beyond terrible when dealing with things like, startup, channel changing, dealing with multiple tuner cards, etc.
Thirdly, the code base for MythTV has become one hell of a clusterfucked mess. Go spend some time actually studying it, before replying on this one.
And well, to not put too fine a point on it, the straw that finally broke the camel's back for me, is MythTV's incessant need to extend the protocol in ways that completely break backwards compatibility. MythTV_PlugIn has to connect to the backend via the backend protocol regularly to receive scheduling notifications, and to post scheduling changes to the backend. This is not easily done without it. However, MythTV's changes have always required that we at the very least change the MYTH_PROTO version numbers to match, and most recently, they have added a hash number to the MYTH_PROTO screen that CHANGES WITH EACH VERSION OF THE SOFTWARE, and REQUIRES that I go into each fucking version of MythTV and PULL THE HASH OUT so that our plugin can talk to it...
So yeah, I've had enough. Discussion over. None of you are writing this code, I am... If you guys want MythTV to go forward into .25, then somebody will need to claim ownership of it, that isn't me, or golgoj4 (as he has enough on his plate.)
-Thom
-
VDR doesn't really care about how it gets its data. Historically VDR supported DVB-S full featured cards only. These days there is support for basically anything DVB, ATSC,PVR. With the move to use plugins for tuner support, it seems to be fairly easy to add new tuner types.
At the moment, the integration of MythTV into LinuxMCE is much better than the integration of VDR. Especially during setup. Also, MythTV was designed to be client/server from the beginning, whereas VDR had to be extended using plugins to support the LinuxMCE client/server architecture. Another MythTV plus (for people in the UK) is the Red Button support, some kind of MHP system.
VDR has one big advantage: It is small, and has a VERY well defined plugin-architecture. VDR lacked flexible and automatic scheduling? Someone wrote a scheduling plugin for it that extends it way above what I need. VDR had needed a hardware to output video to a TV? Someone wrote a plugin to allow the regular gfx adapter to be used.
For me, VDR excels in its ability that it COULD be VERY well integrated into LinuxMCE, as EVERYTHING can be customized. However, nobody is around atm, that has a real urge to invest time in it atm.
-
It is my intention to first investigate what will need to be written, and then start writing plugins to better integrate VDR into LinuxMCE.
It is literally my intention to be able to configure everything from the setup wizard, and then be able to use TV once configured, without manual intervention.
-Thom
-
Without a doubt, the Live TV/ PVR stability is one thing that causes me the most headaches. I can live with those instabilities as I am a very technical person. My wife on the other hand has been very patient with reboots and no TV because I am not home. In the past month I have tried XBMCbuntu, and Mythbuntu and although they both may have a better UI they are both lacking in how effective LinuxMCE can be as a whole house entertainment/control system. I currently am using my own bastardized version of myth that supports the Ceton capture card. @ times things work ok, but more often than not I need to restart live tv when channel changing fails. I would love to see VDR support for the CETON card. I know the ceton card supports IPTV so it may not be that difficult. I can't pledge to much as far as programming is concerned, simply because I have a 2 year old and a 1 year old. I can however test the hell out of things and quite possibly do some debug work, as I have been able to familiarize myself with players and plugins with the help of Thom and some others. With Golgoj great work on the UI, I think this is the next black cloud hanging over LMCE.
-
In case anyone is interested in IPTV with VDR, the plugin is fairly well documented http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ - basically, if vlc can display a the stream, VDR can use it.
-
Posde,
Does VDR have support for Schedules Direct? Not sure how I would get my guide data populated. Don't know a whole lot about VDR. I would be willing to fuck with it though if it would give me a stable live tv / PVR platform.
Thanks,
Kevin
-
Is VDR already distributed? If not it is no valid replacement on a distributed system.... I agree that current mythtv is not that stable. maybe we have more luck when 1204 comes out... can't wait ;-)
-
I would think that Myth 0.25 is going to be a huge improvement over 0.23 in terms of integration. It really looks like the Myth devs have put some thought into how it integrates into other things. The services API exposes a lot of the set-up and operational aspects of MythTV to external control, which in theory could be put into the LMCE Myth plugin. Similarly, the Myth System Events could be used to send DCE messages to indicate to the DCErouter (and the rest of the LMCE system) what Myth is doing.
http://www.mythtv.org/wiki/Services_API
The Capture service is a series of APIs related to the capturing of recorded content. It includes methods of settings up capture devices, card inputs, and may also be expanded in the future to more directly control those interfaces.
The Channel service is a collection of methods for editing channels, adding channels, deleting channels, and modifying lineups and XMLTV services.
The Content services provides a means of serving video, music, and image content from your MythTV system's collection. Images can be dynamically scaled and served by the backend according to your request.
The DVR service allows the programmer to interface with recorded metadata in a variety of ways.
The Frontend service is actually run on Frontend systems (default port: 6547) and allows query of location, playback status, sending remote control messages, and sending popup messages, among other tasks.
The Guide service is a group of methods for accessing the program guide information for use in scheduling, and guide grid applications.
The Myth service is dedicated to MythTV specific settings, and is a series of utility APIs for influencing the way MythTV works on a low level including Storage Group configuration, settings modification and query, hardware profiling, and database backup and repair.
The Video service is used to query and modify video metadata, look up metadata, add new videos to the library, and other video-library-specific functionality.
http://www.mythtv.org/wiki/MythTV_System_Events
* Recording pending
* Recording started
* Recording finished
* Recording deleted
* Recording expired
* LiveTV started
* Playback started
* Playback stopped
* Playback paused
* Playback unpaused
* Playback program changed
* Master backend started
* Master backend shutdown
* Client connected to master backend
* Client disconnected from master backend
* Slave backend connected to master
* Slave backend disconnected from master
* Network Control client connected
* Network Control client disconnected
* mythfilldatabase ran
* Scheduler ran
* Settings cache cleared
I've un-installed the MythTV plugins from my test LMCE system, and am looking at getting Myth 0.25 running and stable from the infrastructure point of view on my 10.04 LMCE test system. I'm a SysAdmin, not a programmer, so the LMCE Plugins are beyond my ability and available time for the foreseeable future. If a real programmer wants to take a crack at the plugins, I'm more than willing to help at the infrastructure layer and with testing (although it'll have to be in a couple of weeks; my z/OS final exams are coming up soon!).
BTW, 12.04 will bring other complexities with it due to the re-basing of the kernel, drivers and utilities, and user-land, so it may be better to make the new Myth (and other major infrastructure changes like qOrbiter) work on 10.04 first, and then port forward to 12.04.
Hope that helps!
/Mike
-
Is VDR already distributed? )
We utilize it in a distributed manor, using streamdev and remotetimer.
-
Just dropping in and got no clue if it's useful as a solution (better reviewed as not useful than undiscovered great potential): https://www.lonelycoder.com/
Please ignore if misplaced.
-
I would think that Myth 0.25 is going to be a huge improvement over 0.23 in terms of integration. It really looks like the Myth devs have put some thought into how it integrates into other things. The services API exposes a lot of the set-up and operational aspects of MythTV to external control, which in theory could be put into the LMCE Myth plugin. Similarly, the Myth System Events could be used to send DCE messages to indicate to the DCErouter (and the rest of the LMCE system) what Myth is doing.
http://www.mythtv.org/wiki/Services_API
The Capture service is a series of APIs related to the capturing of recorded content. It includes methods of settings up capture devices, card inputs, and may also be expanded in the future to more directly control those interfaces.
The Channel service is a collection of methods for editing channels, adding channels, deleting channels, and modifying lineups and XMLTV services.
The Content services provides a means of serving video, music, and image content from your MythTV system's collection. Images can be dynamically scaled and served by the backend according to your request.
The DVR service allows the programmer to interface with recorded metadata in a variety of ways.
The Frontend service is actually run on Frontend systems (default port: 6547) and allows query of location, playback status, sending remote control messages, and sending popup messages, among other tasks.
The Guide service is a group of methods for accessing the program guide information for use in scheduling, and guide grid applications.
The Myth service is dedicated to MythTV specific settings, and is a series of utility APIs for influencing the way MythTV works on a low level including Storage Group configuration, settings modification and query, hardware profiling, and database backup and repair.
The Video service is used to query and modify video metadata, look up metadata, add new videos to the library, and other video-library-specific functionality.
http://www.mythtv.org/wiki/MythTV_System_Events
* Recording pending
* Recording started
* Recording finished
* Recording deleted
* Recording expired
* LiveTV started
* Playback started
* Playback stopped
* Playback paused
* Playback unpaused
* Playback program changed
* Master backend started
* Master backend shutdown
* Client connected to master backend
* Client disconnected from master backend
* Slave backend connected to master
* Slave backend disconnected from master
* Network Control client connected
* Network Control client disconnected
* mythfilldatabase ran
* Scheduler ran
* Settings cache cleared
I've un-installed the MythTV plugins from my test LMCE system, and am looking at getting Myth 0.25 running and stable from the infrastructure point of view on my 10.04 LMCE test system. I'm a SysAdmin, not a programmer, so the LMCE Plugins are beyond my ability and available time for the foreseeable future. If a real programmer wants to take a crack at the plugins, I'm more than willing to help at the infrastructure layer and with testing (although it'll have to be in a couple of weeks; my z/OS final exams are coming up soon!).
BTW, 12.04 will bring other complexities with it due to the re-basing of the kernel, drivers and utilities, and user-land, so it may be better to make the new Myth (and other major infrastructure changes like qOrbiter) work on 10.04 first, and then port forward to 12.04.
Hope that helps!
/Mike
The most popular vote among the devs is to dump myth altogether either by adapting VDR or building our own TV player from scratch. The direction myth is going is making it harder, not easier, for us to control it, because it is trying to control everything.
I personally have not had the issues a lot of people groan about, but then I only use it for OTA, for which it has served my purposes well, save the heaps of lag performing any function (turning on, changing channels, etc). Possy has said that .25 will not be integrated into 1004, and I am not sure further discussion is warranted. I understand that reading the box makes it seem more suited to our purposes, but those who know and wrote the current integration say otherwise. Thom has washed his hands of it, and possy has said no. Unless super magic dev who knows our architecture and myths new APIs comes in and uses voodoo power to make everything gravy, I don't think anyones mind is going to change.
-
Unless super magic dev who knows our architecture and
...
uses voodoo power to make everything gravy
You can just refer to golgoj4 by his name, you know.
-
Hello Guys,
I would like to continue to have the possibility to use Mythtv or VDR, because there is a lot of countries (ej.Argentina where I came from) that still uses analog tv signal, and PAL will keep with us for at least the next 9 years.
Also, Brasil, Chile, Perú, Argentina, Uruguay, Venezuela, are moving to ISDB-T as digital transmition. I have LMCE 1004 runing with a USB isdb-t tuner dongle and is working with mythtv, but not works on VDR.
Mythtv 0.25 supports HE-AAC LATAM audio (that is used in Latin America), and I tested and it works perfect, I read that VDR couldn't decode this codec, I couldn't make it work with isdb-t.
Thanks all
Hernan
-
bugui,
nobody said, that we will remove mythtv from 1004. What *I* do say is, 1004 won't have MythTV .25 integrated ootb. At least, that's how it looks atm.
-
Hi,
Also, Brasil, Chile, Perú, Argentina, Uruguay, Venezuela, are moving to ISDB-T as digital transmition. I have LMCE 1004 runing with a USB isdb-t tuner dongle and is working with mythtv, but not works on VDR.
Mythtv 0.25 supports HE-AAC LATAM audio (that is used in Latin America), and I tested and it works perfect, I read that VDR couldn't decode this codec, I couldn't make it work with isdb-t.
which isdb-t usb dongle are you using with mythtv? and how did you make it work under lmce?
TIA,
Paulo