[mythtv] mythtv-dev Digest, Vol 124, Issue 17
Joel Sjögren
joelsjogren.wii at gmail.com
Mon Jun 24 17:08:57 UTC 2013
Could you specify which file is the most interesting?
2013/6/18 Joseph Mills <josephjamesmills at ubuntu.com>
> The services api kinda has support for live TV. This is what I do for my
> app. I make the user add there startup channel then when they press watch
> TV it starts recording that channel and opens it up in my native player. It
> also loads a list of all the channels via sqlite. Then if user changes
> channel it removes the recording that was just recorded and starts to
> record the selected channel and starts to play it. The channels are always
> behind but it is a work around for now. If any one would like to help me
> with this app my code is on githiub well it has not been updated in a
> couple of days but it is there github.com/bobweaver/mythtv-qml
>
> Thanks
>
> Joseph Mills
> On Jun 18, 2013 8:00 AM, <mythtv-dev-request at mythtv.org> wrote:
>
>> Send mythtv-dev mailing list submissions to
>> mythtv-dev at mythtv.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>> or, via email, send a message with subject or body 'help' to
>> mythtv-dev-request at mythtv.org
>>
>> You can reach the person managing the list at
>> mythtv-dev-owner at mythtv.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of mythtv-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Wii frontend (Chris Pinkham)
>> 2.
>>
>> http://code.mythtv.org/cgit/mythtv/commit/?id=7e250bc1b1385bbaba45c71ce7db9e1173180707
>> - wow! (Warpme)
>> 3. Re: Wii frontend (Michael T. Dean)
>> 4. Re: Wii frontend (George Nassas)
>> 5. Re:
>>
>> http://code.mythtv.org/cgit/mythtv/commit/?id=7e250bc1b1385bbaba45c71ce7db9e1173180707
>> - wow! (David Engel)
>> 6. Re: Wii frontend (Bill Meek)
>> 7. Re: Wii frontend (Chris Pinkham)
>> 8. Re: Wii frontend (Chris Pinkham)
>> 9. Re: Wii frontend (Joel Sj?gren)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 17 Jun 2013 09:12:27 -0700
>> From: Chris Pinkham <cpinkham at bc2va.org>
>> To: Development of MythTV <mythtv-dev at mythtv.org>
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID: <20130617161227.GA17573 at pooh.bc2va.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>> * On Mon Jun 17, 2013 at 12:16:43AM -0400, George Nassas wrote:
>> > When the recordings and videos lists merge won?t myth end up with
>> > a single ID to reference any kind of video material? I?ve never seen
>> > any discussion to that effect but it seems like an obvious move. A
>> > welcome one too. Assuming I?m right, that would be the time to unleash
>> > client-breaking changes.
>>
>> There will be an ID per file. The recordings and videos will still
>> be stored separately, but they'll share a common set of tables for
>> things like the file(s) behind the recording or video and the
>> seektables associated with those files. A recording might have
>> two files due to an interrupted recording process or multiple
>> resolutions such as the original and a transcode or both HD and SD
>> versions recorded. Videos could be similar or have multiple parts
>> as is supported currently.
>>
>> We have also talked about replacing the chanid/starttime with a
>> unique RecordingID, but I'm not sure if Michael T. Dean is rolling
>> that into the updated schema or if it is feature creep. The
>> original schema design for the shared tables was something that
>> I was working on 4 years ago but as with always, our TODO lists
>> are a mile long and real life has some of us like me moving at
>> a snail's pace so I passed it off.
>>
>> --
>> Chris
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 17 Jun 2013 18:26:49 +0200
>> From: Warpme <warpme at o2.pl>
>> To: MythTV - Dev list <mythtv-dev at mythtv.org>
>> Subject: [mythtv]
>>
>> http://code.mythtv.org/cgit/mythtv/commit/?id=7e250bc1b1385bbaba45c71ce7db9e1173180707
>> - wow!
>> Message-ID: <51BF38C9.8070409 at o2.pl>
>> Content-Type: text/plain; charset="iso-8859-2"; Format="flowed"
>>
>> Wow,
>> Under heavy tests (additional 50 test rules scheduling 4 blocks of 16xHD
>> concurrent recordings) this commit reduces my schedule times by 2x.
>> (from 24-28sec to 12-14 sec).
>>
>> Just quick q: is it safe to backport it to current 0.26-fixes?
>>
>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: warpme.vcf
>> Type: text/x-vcard
>> Size: 83 bytes
>> Desc: not available
>> URL: <
>> http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130617/22967be8/attachment-0001.vcf
>> >
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 17 Jun 2013 12:30:13 -0400
>> From: "Michael T. Dean" <mtdean at thirdcontact.com>
>> To: Development of MythTV <mythtv-dev at mythtv.org>
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID: <51BF3995.3000003 at thirdcontact.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 06/17/2013 12:12 PM, Chris Pinkham wrote:
>> > * On Mon Jun 17, 2013 at 12:16:43AM -0400, George Nassas wrote:
>> >> When the recordings and videos lists merge won?t myth end up with
>> >> a single ID to reference any kind of video material? I?ve never seen
>> >> any discussion to that effect but it seems like an obvious move. A
>> >> welcome one too. Assuming I?m right, that would be the time to unleash
>> >> client-breaking changes.
>> > There will be an ID per file. The recordings and videos will still
>> > be stored separately, but they'll share a common set of tables for
>> > things like the file(s) behind the recording or video and the
>> > seektables associated with those files. A recording might have
>> > two files due to an interrupted recording process or multiple
>> > resolutions such as the original and a transcode or both HD and SD
>> > versions recorded. Videos could be similar or have multiple parts
>> > as is supported currently.
>> >
>> > We have also talked about replacing the chanid/starttime with a
>> > unique RecordingID, but I'm not sure if Michael T. Dean is rolling
>> > that into the updated schema or if it is feature creep.
>>
>> Yes, I'll be changing recorded to use a single recordedid, rather than
>> the chanid/starttime. But, as Chris mentioned, videos and recordings
>> will have distinct IDs, as they will still be distinct items. Much of
>> the other "supporting" metadata, though, will be shared.
>>
>> > The
>> > original schema design for the shared tables was something that
>> > I was working on 4 years ago but as with always, our TODO lists
>> > are a mile long and real life has some of us like me moving at
>> > a snail's pace so I passed it off.
>>
>> And I got a bit distracted with real life, too, but should be working on
>> this after 0.27.
>>
>> Mike
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Mon, 17 Jun 2013 12:51:07 -0400
>> From: George Nassas <gnassas at mac.com>
>> To: Development of MythTV <mythtv-dev at mythtv.org>
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID: <4A4BBB2C-EBDA-4D90-B4A9-40EE9D89267A at mac.com>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> On 2013-06-17, at 12:30 PM, Michael T. Dean wrote:
>>
>> > Yes, I'll be changing recorded to use a single recordedid, rather than
>> the chanid/starttime.
>>
>> Yay!
>>
>> > But, as Chris mentioned, videos and recordings will have distinct IDs,
>> as they will still be distinct items. Much of the other "supporting"
>> metadata, though, will be shared.
>>
>>
>> To clarify: within the same number space? IOW, you won?t be able to have
>> a recording id 10 and a video id 10. 10 might be a recording, 11-15 videos,
>> the next few recordings, etc.
>>
>> The payoff would be to trim the current parallel APIs where you have
>> start/stop/restart/delete HLS stream for recordings and
>> start/stop/restart/delete HLS stream for videos and the only real
>> difference is how you refer to the media. Same for artwork etc. I imagine
>> you would end up saying ?start me a stream on media #26? and the right
>> thing happens behind the scenes. Just askin?
>>
>> Rereading your statement I think I?m imagining it wrong.
>>
>> - George
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130617/0aebd103/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Mon, 17 Jun 2013 13:17:24 -0500
>> From: David Engel <david at istwok.net>
>> To: Development of MythTV <mythtv-dev at mythtv.org>
>> Subject: Re: [mythtv]
>>
>> http://code.mythtv.org/cgit/mythtv/commit/?id=7e250bc1b1385bbaba45c71ce7db9e1173180707
>> - wow!
>> Message-ID: <20130617181724.GB10550 at opus.istwok.net>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Mon, Jun 17, 2013 at 06:26:49PM +0200, Warpme wrote:
>> > Wow,
>> > Under heavy tests (additional 50 test rules scheduling 4 blocks of
>> > 16xHD concurrent recordings) this commit reduces my schedule times
>> > by 2x.
>> > (from 24-28sec to 12-14 sec).
>> >
>> > Just quick q: is it safe to backport it to current 0.26-fixes?
>>
>> It's probably safe for 0.26, but it's not something I'll be pursuing.
>> At this point, most deveoper energy should be focused on preparing
>> 0.27 for freeze, testing and release.
>>
>> David
>> --
>> David Engel
>> david at istwok.net
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Mon, 17 Jun 2013 16:04:41 -0500
>> From: Bill Meek <keemllib at gmail.com>
>> To: mythtv-dev at mythtv.org
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID: <51BF79E9.7000504 at gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 06/16/2013 10:19 PM, Chris Pinkham wrote:
>> ...
>> > The Services API is a work in progress, and input from users of the API
>> > (or people who understand MythTV and can add new endpoints) is always
>> > welcome. There are several different projects going on right now
>> > which make use of the API to create frontends on various devices.
>>
>> Can I interest you in this one?
>>
>> http://code.mythtv.org/trac/ticket/11386
>>
>> The 1st part of the patch adds this:
>>
>> http://<BackendServerIP>:6544/Myth/GetConfigurationInfo
>>
>> and the 2nd adds to the response of the existing:
>>
>> http://<BackendServerIP>:6544/Myth/GetStorageGroupDirs?GroupName=Streaming
>> (etc.)
>>
>> Both were done based on problems found helping MythTV Android
>> Frontend users.
>>
>> It allows a Services API client to alert the user that the backend
>> has build/configuration choices that will prevent the client from
>> running properly.
>>
>> --
>> Bill
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Mon, 17 Jun 2013 14:17:51 -0700
>> From: Chris Pinkham <cpinkham at bc2va.org>
>> To: Development of MythTV <mythtv-dev at mythtv.org>
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID: <20130617211751.GA26683 at pooh.bc2va.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>> * On Mon Jun 17, 2013 at 04:04:41PM -0500, Bill Meek wrote:
>> > Can I interest you in this one?
>> >
>> > http://code.mythtv.org/trac/ticket/11386
>>
>> Added this to the top of TODO list to take a look at. Thanks.
>>
>> --
>> Chris
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Mon, 17 Jun 2013 14:22:56 -0700
>> From: Chris Pinkham <cpinkham at bc2va.org>
>> To: Development of MythTV <mythtv-dev at mythtv.org>
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID: <20130617212256.GB26683 at pooh.bc2va.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>> * On Mon Jun 17, 2013 at 12:51:07PM -0400, George Nassas wrote:
>> > To clarify: within the same number space? IOW, you won?t be able to
>> > have a recording id 10 and a video id 10. 10 might be a recording,
>> > 11-15 videos, the next few recordings, etc.
>>
>> This isn't what was planned so far. RecordID and VideoID (or whatever
>> that field is called are in separate tables). FileID is in another
>> table. A RecordID could have multiple FileID's and a VideoID could
>> have multiple FileID's. Technically, a RecordID and a VideoID could
>> share the same FileID as well.
>>
>> > The payoff would be to trim the current parallel APIs where you
>> > have start/stop/restart/delete HLS stream for recordings and
>> > start/stop/restart/delete HLS stream for videos and the only
>> > real difference is how you refer to the media. Same for artwork
>> > etc. I imagine you would end up saying ?start me a stream on
>> > media #26? and the right thing happens behind the scenes. Just askin?
>>
>> It already is this way sort of. The base HLS service calls just
>> take a filename and return a HLS ID. There are wrappers around this
>> to allow you to easily startup a HLS stream for a recording using
>> starttime and chanid or for a video using the video ID.
>>
>> > Rereading your statement I think I?m imagining it wrong.
>>
>> I imagine that once the new schema is in place, there might be a
>> way to say "gimme a HLS stream for this FileID", but that might
>> be something just rolled into the on-demand HLS patch if the
>> schema is there already.
>>
>> --
>> Chris
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Tue, 18 Jun 2013 12:31:55 +0200
>> From: Joel Sj?gren <joelsjogren.wii at gmail.com>
>> To: mythtv-dev at mythtv.org
>> Subject: Re: [mythtv] Wii frontend
>> Message-ID:
>> <
>> CAJq7yX674iYG5eGQqXWxnBnr428rf1oeffYrT2amyP9wp2ipnw at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> 2013/6/14 Joel Sj?gren <joelsjogren.wii at gmail.com>
>>
>> > I've also just heard about xbmc's support for mythtv (while reading
>> about
>> > mythtv for the xbox), so I'm going to see how they've gone about it.
>> >
>>
>> The xbmc-pvr-addons include mythtv support through a library called cmyth.
>> It can be found here: https://github.com/cmyth/cmyth. It appears that,
>> unlike the services api, cmyth supports livetv.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130618/debe37c5/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>>
>> End of mythtv-dev Digest, Vol 124, Issue 17
>> *******************************************
>>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130624/6d0f0b58/attachment.html>
More information about the mythtv-dev
mailing list