MythTV Observations, ugh.

[tschak909]

Ugh,

Okay, the whole MythTV plugin, now that I have working channel changing in, seems a wee bit forced.

There is a definite disconnect between recording the shows, and playing them back, when I delete a show inside the media browser, it still shows up in MythTV's recordings bin. I know the MythTV recordings bin isn't supposed to really be used, however, it is the only place I can see definite text relating to TV episodes (because they show up in the Media view as just "MythBusters", etc.). I know that the file-grid wasn't meant to handle much more than 20 or so characters of text, but having 10 show recordings show up as "MythBusters" can be a bit confusing, that I have to go into each individual one and click on it to see a synopsis.

Just my observations, don't know if any work is being done in here besides the SchedulesDirect stuff (which I still haven't recieved an update request for., even though I have modified my hosts to add the beta updates site.)

-Thom

[1audio]

I agree that the Myth integration leaves something to be desired. Perhaps someone can figure out how to build a set of Myth skins that work with Pluto so the integration is less kludgy. Pluto has better surfing ability but Myth has much more information about the content. The Music capabilities also are weak and need work. Nothing that time, energy, money or all three can't fix.

[dopey]

It would take a bit more than a skin.

My vision, which I honestly don't have the time to realize myself, is to have mythtv as the media director and orbiter. I believe this falls in line with LinuxMCE as it already used the QT libraries and supports alpha-blending in the OSD, that would need to be expanded however. The problem is LinuxMCE always has media playing. That means the MythUI would have to be completely re-engineered so all work is done in the player and the player is actually running the whole time. This means all the theming would be done at the OSD level, which is why alpha-blending support in the OSD is important. The MythTV internal player is actually quite advanced now, so we can do away with having to launch an external player to play the movies, music, etc. for most things. Beyond this the theming capability would also need to be exanded to allow LinuxMCE to change menus on the fly (during the Orbiter regeneration) and, of course, linking to Orbiter libraries to send and receive LinuxMCE events.

There is a lot more to this, such as which database should be used to store media meta-data, MythTV's or Pluto's. Personally I think MythTV's is slightly better, but can use some improvement that can be gained by merging the two concepts for both MythTV and Pluto media meta-data storage.

[darrenmason]

Dopey,

I actually think it should go the other way. ie; remove more and more of the mythTV screens and replace them with the linuxMCE GUI. I think that this would have been originally done in Pluto if the application level integration (via APIs) was easier.
That is not to say that there is not some good technology in MythTV that should be utilised (ie; the stuff in the plugins) but I think this should have orbiter interfaces for it.

The problem with not doing that is the loss of control you get when you hand control over to the application GUI (MythTV) so, for instance, if you want to popup a priority window with a picture of who is at the door it suddenly gets really hard. Whereas if you maintain that GUI control then things like this can be incorporated easier. Ultimately I see an Orbiter as the GUI for accessing any of the devices in you home and MythTV is just one of them.

[tschak909]

I agree with darrenmason.

-Thom

[dopey]

Your point is well taken... but... It would be next to impossible to get those plugins to run without such a merge in MythTV and we would continue to be dependant on another external player to actually play the media, which does cause several issues.

Actually, what was suggesting was to use the MythTV player and it's OSD capability. The rest of the frontend would be useless to LinuxMCE. The GUI, would only be the theme engine for the OSD and the player. Having the player save it's location, stop playing, and then instantly show something else of interest, or even show it in PIP window wouldn't be too difficult at that point. Also, there are ideas in the myth database that I think should be in LinuxMCE. This does not require using the Myth database, but I think it would be beneficial so people can access the media the various apps that support the Myth protocols.

[darrenmason]

It's good to see some discussion on this sort of stuff (probably should be in the developers group though).

I don't think that we want to be coupled to MythTV too closesy. Not because its not a good product or anything but moreso due  to it restricts our development to the timeline and development of the MythTV project. 

Integrating at the API level may be more work (in building GUIs) but gives us more flexibility in producing a good solution. It also enables us to have a common GUI to multiple applications allowing best of breed implementation. eg: VDR may be a better liveTV/PVR implmentation for some people using different hardware.

I understand that we might not get some of the best bits of some of the applications, like OSD capabilities, but if the project is to be more than a MythTV wrapper then I think that is what is needed.

Again, this is my opinion and I appreciate yours.

I am interested in the ideas from the Myth database that you think would be useful. What exactly are they?

[dopey]

A brief example is how meta data is stored in Myth vs. Pluto. Both are actually sound implementations with pro's and con's. Pluto uses bridge tables to link what the meta-data is and the actual data (One record stores "Title" and the other stores the actual title name), Myth has columns for Title, etc. With Myth you will always know how to retrieve the title as it won't change. This makes GUI development easier as you can predict what data should be displayed and what should be suppressed. With Pluto you actually have the option for multiple titles, etc. This is both a good think and bad thing. For example which title should be displayed, or emphasized.

Also if we use the Myth database the other built in functions of myth can access it, such as its built in media streaming capabilities (i.e. stream media to PS3).

I agree that we would want to limit how much we merge into MythTV. That's why I'm discussing smaller features that we would rely on anyhow. We will always be dependant on the player, so it makes sense to me to expand how we use it. Also, I think Myth would be very open to expanding the OSD theming capabilities. Once that is done, all the GUI work would be done at the theme level. At least that's how robust the theming engine would need to be.

Another problem with my approach is licensing. I believe MythTV uses the MIT license and what LinuxMCE uses... no one really knows for sure... that would present a problem with linking the Orbiter specific stuff with Myth and we definitely would not want to merge that code into Myth as it has no place there...

I don't have any experience with VDR so don't really know the pro's and con's of using it. I'll look it up.

I agree, this should be in the Developer forum. I originally intended to post it there, but I wasn't really going to bring this up until our current Myth issues have been resolved... I just got carried away when answering the question...

[1audio]

I believe both Myth and Pluto use Xine for playback. In a sense its two ways to get to the same place. I don't think Myth uses compositing for its transparency which is why it has been easier to port to different hardware. I think the benefit of VDR is better utility for uses outside of the US more than hardware.

[dopey]

I believe both Myth and Pluto use Xine for playback. In a sense its two ways to get to the same place. I don't think Myth uses compositing for its transparency which is why it has been easier to port to different hardware. I think the benefit of VDR is better utility for uses outside of the US more than hardware.

Actually, that's not true. Myth gives you the option to use Xine, mplayer, or whatever for playback; but it has an internal player as well. I've been using and still do use the internal player to play all my video's including the one's using the brand new codecs, such as x264.

You are right that Myth doesn't use compositing for transparency... That's one of the area's that LinuxMCE also needs work on, as Paul points out.

[1audio]

I stand corrected. Are the capabilities different? I have been playing with the TVTime extensions in Xine (Descaler) and they seem to work if you have enough horsepower, but don't work with the composting.

[dopey]

The capabilities are different. The deinterlacer, all picture controls, cutlists, etc. that is used for normal MythTV recordings are also used for the other videos. This gives consistent control for all media. The main reason that MythTV wasn't used as the default player for other videos in the past was because it didn't support some of the major codecs or the DVD Menu Navigation. That it is no longer true.

I don't MythTV can use the TVTime extensions, but I could be wrong as I've never tried.

[bulek]

Hi,

I'll add few my thoughts, since I've been using both systems for quite some time now.

- I have MD connected to LCD TV and I see no really important reason why I would use mythtv instead of LCD's tuner for live tv. Commercials are on ever 5 minutes anyway, so you can do all your work in between (whatever you like to do: toilet, wife)... :-). If live TV over mythtv will hickup once in 3 hours, this is it. Standards for live TV devices are really high and users won't accept anything but 100% working solutions. Why risk with mythtv, all that buffering, when you can use already present tuners on tv...

- I mainly use mythtv only as PVR backend that records all stuff that is setup to do records. Now, with mytheb, I even don't need to run mythfrontend anymore

- I miss some usefull mythtv plugins more that just mythfrontend (mythnews, mythweather, mythphone, mythzoneminder...) and maybe some of newer ones I don't know. So I'd integrate those as external standalone applications, until lmce will have its own counterparts...

- I think that real integration of mythtv is to some extent pointless right now, when mythtv is developed to be more a standalone all-you-need application than useful backend that can be easily integrated into other systems....

Only my thoughts,

regards,

Rob.

[dopey]

I truly don't understand your first point... I haven't had any problems with MythTV and LiveTV in years... and if you use the LCD for live TV then you can't time-shift, which is a major reason for even doing any of this... no one would except that as an option for LinuxMCE...

Your third point says you would rather create several standalone apps then integrate LinuxMCE with MythTV more so you can use existing plugins??? That really doesn't make sense to me...

As to your fourth point... it's almost completely false... even you kind of state that in your second point... MythTV has a good set of protocols so several apps can use Myth functions and there are a lot of apps that do this. I'm just suggesting that we expand on that so the OSD theming can be used with the MythTV player and that we use that with LinuxMCE.

[tschak909]

also the lack of being able to deal with the commercial flagging ____REALLY____ is a step down.... ugh, as is the lack of direct ability from linuxmce without circumenting the mythtv stuff to intelligently schedule recordings.... searching for it in the context of the guide really really really REALLY sucks.

-Thom