|
Rockbox mail archiveSubject: Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)Re: Automatic multi-resume feature for podcasts and audiobooks (FS#11748)
From: sideral <asieoniezi_at_gmx.net>
Date: Thu, 06 Jan 2011 02:50:17 +0100 Paul Louden <paulthenerd_at_gmail.com> writes: > I responded to it with "sounds like" because I literally mean that's > what it appears like to me. I thought I had responded to your actual > objections as well, further down, but since you linked me to a > flyspray task rather than spelling them out I was left to my own > ability to pick them out of a post that wasn't just about your > objections to using bookmarking. This may have been a misunderstanding. I actually meant to spell out my reasons for not basing autoresume on bookmarks in my e-mail messages (but probably didn't do a good job). I was referring to that Flyspray comment not as the main source of these reasons, but only in a personal parenthetic/footnote remark meant to illustrate the bookmarking system's configuration and implementation complexity by way of the hassles I've had with it. The points I wanted to make were: * Bookmarks (as they exist today) are much harder to use and to configure correctly, and have much higher implementation complexity, than the proposed autoresume feature. * Basing autoresume on bookmarks is going to make bookmarks even harder to use, configure, and get right. * Yet, the inquisition is all over me for a feature that is comparatively trivial to use and simple to configure. > I'd be happy to have you state your objections clearly so I could > understand better. My reasons (not objections) for basing autoresume on the DB rather than on bookmarks were: * Code complexity: No need to do any explicit file I/O, or to parse / write text-based bookmarks. The DB already handles I/O and parsing/unparsing. * Simplicity due to similarity to existing code: Reading and writing resume information is done in the same functions and in the same way as reading/writing DB-based runtime statistics (play count, play time, etc.). * Performance: The DB typically already has the required resume data cached in the critical path during automatic track changes (the DB is consulted when the codec initiates a track change or earlier), and the metadata write is already nicely deferred to not interfere with track buffering. * Features: The resume offset can be queried to generate interesting database views. For example, in my tagnavi_custom.config file I have defined a view that lists all unfinished podcasts. * No need to invent a new file format (or extend an existing one) to store per-file resume points. * I prefer storing per-file metadata in the DB rather than in files because having a per-file bookmark would clutter the filesystem. > [...] > As well, the advantage of bookmarks is that auto resume would always > be available, whether or not a user was using the database, rather > than forcing them to. This seems fairly significant to me, since there > may not always be space for the database. It can grow quite large if > there's a large number of files. Yes, that's a shortcoming of any DB-based feature (DB browser, runtime statistics, track rating), but no one _forces_ anyone to use the DB. No feature is for everyone. Various people have suggested to mitigate this issue by allowing tracks to be added to the DB as they are played. That would allow all users to take advantage of autoresume without requiring the DB to be initialized with all tracks. Cheers, sideral Received on 2011-01-06 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |