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

[H. Langos]

Hi Philip,

On Tue, Aug 18, 2009 at 05:48:14PM +0000, address@hidden wrote:
> 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)

gnupod_find --noheader

> and playlist selection in find would obsolete
> dumpsongs. find also handles utf8 correctly, which dumpsongs doesn't 
> right now.

Well, "handling" utf8 is too big a word ... It adjusts the display width 
of multicharacter code points but that will not be needed for
script-friendly output anyway.

>> 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.

gnupod_find "--rawprint" option will switch off that stringify functions.
There are some more, like soundcheck and volume.. and "unixpath" which is 
a completely artificial attribute.

currently you can only switch rawprint on and off completely but the syntax
of the --view parameter could be extended to allow raw/cooked output of
individual attributes e.g. --view title,album,:soundcheck,lastplayed

>> 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.

I'm not sure if I agree here. I think the complexity of the "--filter" option
is way higher. But being unix/script friendly is one of the design goals of
gnupod so there might be merrit to the idea of passing data on stdin.

> 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.

sounds good.

> 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?

Technicaly yes. But I doubt that the iPod firmware pays any
attention to those attributes. Please correct me if I am wrong.

> 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.

On the other hand, if you noticed that one of the songs you have needs to be
reripped, you'll probably not fuzz around with the id3tags of that song.
You'll probably just rip that thing again and dump it on your ipod. If there
was anything to be done with the tags, you probably would have done it to
the original file long ago and that data will be in the attributes, no
matter if the file has any tags in it.

In any case such a script would be a quick hack. The correct way would be 
to remove the file, add the fixed version of it, and adjust the dynamic
attributes (once gnupod_modify sees the light of days ...)

cheers
-henrik