bug-gnupod
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: [Bug-gnupod] Some gnupod scripts I wrote


From: philip . hazelden
Subject: Re: Re: [Bug-gnupod] Some gnupod scripts I wrote
Date: Tue, 18 Aug 2009 17:48:14 +0000

On Aug 17, 2009 6:39pm, "H. Langos" <address@hidden> wrote:
> The functionality of dumpsong sounds a lot like that of gnupod_find, though
> it doesn't yet have a script friendly output format, and the selection by
> playlist is as yet only implemented in gnupod_delete and should rather be
> migrated to the FindHelper.pm module. Did you taka a look at gnupod_find
> and gnupod_delete yet? They are not in the 0.99.8 release but they are
> in the master branch.

I originally wrote dumpsongs before I started tracking the git repo, so I didn't
know about them at the time. You're right that script-output (the header lines
would also have to be removed) and playlist selection in find would obsolete
dumpsongs. find also handles utf8 correctly, which dumpsongs doesn't right now.

> Is "realpath" the same equivalent of gnupod_search's "unixpath" ?

Yeah. I intended to add other :attribs for formatting the raw data, like
:lastplay to stringify the timestamp (like find already does). But I never got
curious about the last-played dates of my collection, so I never got around to
it.

> BTW: I hope I'll find the time to add gnupod_modify (using the same generic
> parameters that gnupod_find and gnupod_delete have) for the next gnupod
> release in order to manipulate all attributes that are available in the
> GNUtunesDB. I'd love to manipulate artwork with the same tools but i'm
> still not sure how to do the user interface...

This is something I was thinking about when making the dumpsongs output
unix-friendly: if modify can read the changes to make from stdin, it would need
to have far less functionality built-in. Tell it on the command line that input
is coming in as (eg.) id, playcount, tracknum, title, and then it can read a
line like "132\t12\t9\tStairway to Heaven" and update the playcount, tracknum
and title fields of the track with that id. Then you can apply sed/awk/perl
filters to the output of find and pass them into modify.

Most of modify's use-cases probably wouldn't need this power, and it might be
worth having simpler ways to handle them. But more complicated stuff, like
renumbering tracks in an album to take account of removed songs, probably
doesn't need to be implemented in modify or allowed for in modify's argv syntax.

On Aug 18, 2009 10:16am, "H. Langos" <address@hidden> wrote:
> Creating an extra gnupod_replace script looks like overkill to me.
> I'd rather do a shellscript that calls gnupod_find to get the unixpath
> and then does a simple "cp". No need to update the GNUtunesDB or the
> iTunesDB...

Correct me if I'm wrong, wouldn't such a script still need to update attributes
like time, filesize and bitrate? And at the same time, it would often be helpful
to update some of the metadata (anything in ID3, for example) while keeping
stuff like playcount and rating the same.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]