I’ve rewritten most of iTunes Library Checker to use some neater import code, it should also be a bit faster. Not quite complete yet, but close to the previous functionality.
#! /usr/bin/env python import Foundation import os import struct library = os.path.expanduser('~/Music/iTunes/iTunes Music Library.xml') db = Foundation.NSDictionary.dictionaryWithContentsOfFile_(library) libpath = Foundation.NSURL.URLWithString_(db[u'Music Folder']).path() tracks = db[u'Tracks'].itervalues() findstr = "find '"+libpath+"' -type f -not -name .aacgained -not -name ._* -not -name .DS_Store | sort" treedata = os.popen(findstr).readlines() missing = [] other = [] missing_files = [] other_files = [] surplus = treedata[:] for track in tracks: location = Foundation.NSURL.URLWithString_(track[u'Location']).path() if not os.path.exists(location): missing.append(track) missing_files.append(str(location)) else: try: surplus.remove(str(location)+'\n') except ValueError: other.append(track) other_files.append(str(location)) missing_files.sort() other_files.sort() surplus.sort() open('surplus.txt','w').writelines(surplus) open('missing.txt','w').writelines(missing_files) open('other.txt','w').writelines(other_files)
You should take a look at the subprocess module from Python 2.4 (it’s compatible with Python 2.3, just copy it over). It has a much nicer API for executing other processes. Most importantly, you won’t need to do your own quoting (which isn’t correct here, btw).
You probably want to use location.encode(’utf8′), not str(location), because the latter is going to raise UnicodeDecodeError if the filenames aren’t entirely ASCII.
Is there any particular reason you’re copying the treedata list? It doesn’t look like you’re reusing it anywhere.
7 hours, 58 minutes after the fact.
Yeah, I think the quoting issue came from the conversion to HTML. I’m using SubEthaEdit’s copy as XHTML, and it doesn’t encode double quotes. I think it should, and I’m reporting a bug now.
I’ve never really used unicode stuff before - I haven’t done that much python stuff since ages ago, but thanks for the tip about that - and I do have non-ascii filenames, so that might be why I was getting some weird results.
(As for the treedata opy, I think I was going to reuse that somewhere, or I may have left it in there to test something else, but I don’t think I do need the copy).
1 day, 15 hours after the fact.
please do file a bug, with source, result and expected result. if your right and double quotes should be encoded it will definitely make its way into our next update.
3 days, 1 hour after the fact.
I’m not sure if it’s a real bug: at least not with SEE, anyway. It seems to be an issue with the way files are parsed for the blogging system.
3 days, 19 hours after the fact.