mattpyne at yahoo.co.uk
Fri Aug 20 12:27:32 UTC 2010
Thank-you for the background.
I can kind'of understand why the upnp video was done this way, but I can't help
thinking that there are plenty of other open-source upnp servers that offer the
functionality of serving a directory tree of media. I think the integration
with MythVideo is more obvious - if you don't use mythvideo, then you want get
videos served, this seems pretty obvious too. MythVideo gives you the nice user
interface and allows the user to easily add the metadata that is important to
the Upnp server, without the metadata it others little over sharing the files
via Samba or similar.
I understand the drawbacks of MythVideo, but I think these are problems to be
address by MythVideo not by the upnp server. Also I understand from a neatness
point of view it might be better for the upnp serving of the videos to be in the
MythVideo plugin, but I think that would be impractical, and lead to duplication
of the upnp code.
Anyway, I have the patch and I am going to submit it. It works lovely for me
and I leave it to powers that be to decide if you want to implement it or
From: David Blain <MythTv at TheBlains.net>
To: Development of mythtv <mythtv-dev at mythtv.org>
Sent: Wed, 11 August, 2010 19:30:15
Subject: Re: [mythtv] UPNP
>From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org] On
>Behalf Of Matt Pyne
>Sent: Wednesday, August 11, 2010 11:37 AM
>To: Development of mythtv
>Subject: Re: [mythtv] UPNP
>Yes and yes. I will submit the patch as soon as I have it ready.
>Sent from my iPhone
>On 11 Aug 2010, at 16:09, Raymond Wagner <raymond at wagnerrp.com> wrote:
>On 8/11/2010 04:37, Matt Pyne wrote:
>Do you have any thoughts on dropping the use of upnpmedia table and serving the
>videometadata table instead? I have a working patch for this and from my point
>of view it is much better because you get the coverart and descriptions of the
>Moving to the `videometadata` table instead of doing its own scan through
>`upnpmedia` is absolutely preferred, however mythvideo is being migrated to use
>storage groups. Does your implementation support the relative paths stored in
>the database >when storage groups are in use? Does it support access to content
>on remote backends, not available on the local file system?
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
When I originally wrote the upnp stack, I had it use the videometadata table.
Some time ago, someone else switched it to use the upnpmedia table. If I
remember correctly this was done due to the fact that the videometadata table
didn't contain data unless the MythVideo plugin was installed on a frontend
(which not everyone has) and a scan was performed. Also, newly added video's
weren't picked up unless by upnp clients unless MythVideo was opened and a new
scan was performed.
I personally feel that the video, music, photos, etc... scanning/tracking
should be part of the backend and not tied to the MythVideo plugin (I also think
it should all be in one table with unique properties stored in related tables,
but that's a different conversation) . I know there is a lot of work being done
to integrate mythvideo, add Storage Group support and use the new
FileSystemWatcher Qt class to detect new files instead of scanning, all of which
will make the final implementation completely different.
Just wanted to give you a little history.
mythtv-dev mailing list
mythtv-dev at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev