[mythtv-users] Set bookmark on pause

Chris Adams rocket at extremelan.net
Mon Feb 22 00:01:16 UTC 2010


On Mon, Jan 18, 2010 at 6:18 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 01/17/2010 12:36 PM, Mike Perkins wrote:
>> Michael T. Dean wrote:
>>>
>>> Yeah, that's one of the reasons for the patch.  It's part of some "smart
>>> preview pixmap" changes that will allow me to finally get rid of the
>>> useless "preview pixmap offset" setting.
>>>
>> Do you have any plans to include a "Don't generate previews" option?
>
> My plan was to reduce the number of options, actually.  :)
>
>> I find them a complete waste of time. Reason: they *never* show
>> anything of relevance. Either I get one (unreadable) page of the
>> credits for the previous program, or a random frame of an advert, or
>> something else equally meaningful. I find them a complete irritation.
>>
>> I would rather not waste time generating the things in the first
>> place. In mythweb particularly there can be a delay in displaying the
>> "recorded" page while these get generated.
>
> MythWeb does have a setting for disabling display of the previews.  You
> would need that, anyway--even if there were a setting to disable preview
> generation.
>
>> In the front end not so much, but they're still pointless.
>>
>> The space is not so important, but is also a waste. And don't tell me
>> "it's only xxKiB (or MiB), what's the problem", because I'm using
>> large block allocation and there is a minimum space reserved for each
>> block on the disk. Perhaps that problem will get resolved when
>> previews can get allocated their own storage area, but I'd still
>> rather not do it at all.
>
> That's something I've been considering doing (though each time I get
> started someone convinces me that it's not worthwhile--even with the
> file system block sizes).  I still might get to it, but it will be part
> of a larger preview generation change.
>
>> Oh, yeah, back on topic. In my household viewing tends to get paused
>> quite a lot due to various interruptions. I'd rather deliberately set
>> a bookmark if I wanted to stop viewing now and resume later than have
>> a whole heap of bookmarks and have to guess which one was relevant.
>
> The bookmarks would be very well organized.  There will be a "main"
> bookmark which will act exactly like the current "there can be only one"
> bookmark (i.e. playback resumes from that bookmark when you start
> playback with play, you jump to that bookmark with the JUMPBOOKMARK (or
> whatever it's called) button, ...).  The auto-generated bookmarks will
> be kept separate from any user-set bookmarks.  (The auto-generated
> bookmarks will likely include the commercial endings in the flag list
> and/or cut-point resume points in addition to the pause bookmarks.  I'm
> also assuming that we'll clear pause bookmarks--perhaps after completing
> a new playback session, we clear the pause bookmarks from the older
> playback session.)
>
> Mike
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

You might be over-thinking it.

XBMC will bookmark on stop, but not on pause. If you want to bookmark,
you press stop. It's one of those things you wonder how you went
without - you'll click a movie you got half-way through last week and
it'll let you resume.

Bookmark-on-stop is better suited to "move rooms and resume watching"
use-case, too, since you actually want to press stop (not pause) on
frontend A before moving to frontend B. Also avoids the need to manage
>1 bookmark so no new dialog needed.

If you do want to pause you can set bookmark manually (then the
program runs on 2 frontends).


More information about the mythtv-users mailing list