IMS_Blog

The solution starts with the useful ActiveWinamp plugin and my struggling to remember enough Visual Basic to write anything useful (because that’s what language all the examples use). From there it degenerates into confusion, bugs, incompetence (on my part), mystery and, finally, something of a solution.

Based on a copy without losing Media Library info example, I knocked up a script to take each track passed via Send to:, copy it, load the copy into the Media Library (hence making it believe it to be a new file), clone the playcount etc info across and get rid of the original from the library. Then reverse the process so the file is in the original location again. That was the starting point anyway—and is actually more or less what one version of the script does. It’s just not the entire story.

The first problem was my nice inserted new file didn’t seem to want to appear in the Media Library. Stranger than that, I could programmatically enqueue the newly created item to the playlist and see it there (and even play it); I could also find its database index—it just didn’t appear in the Media Library (even after refreshing the view, restarting Winamp, etc). I began to think this meant the entire insert method used to add the file was buggy, which would pretty much destroy any of my potential approaches. On the verge of giving up on an “it doesn’t work” basis I accidentally clicked on a smart view that just happened to catch the file I was testing with…and there it was, under that view, in the Media Library. It still took a few minutes to realise what was going on because the file still wasn’t appearing when I listed everything. It turns out that the “type” of the inserted file was left blank. Winamp’s default audio view filters by type=0, so the inserted file wasn’t showing up. My smart view didn’t include type=0. Changing type=0 to type=0 OR type ISEMPTY solved the issue :-) Suddenly the script so far worked and there was once again a visible path to what I wanted to do.

The next problem was that cloning the meta info obviously was buggy in some way. The main indication of that bug was the genre being set to whatever the comment tag of the file was (I use the comment quite a bit for adding additional info onto the files, so I’d really notice that). I abandoned clone in favour of storing playcount, rating and lastplayed in variables and tracking them myself. That meant I could update those successfully and genre wasn’t being horribly messed

At this point I finally got tired of the long winded way in which I was essentially doing two move operations, there and back. Why bother actually moving the file at all? I could just load it as a new item, delete the original item from the Media Library (having stored the meta info), add the meta info to the new item and insert to the library. Using that principle I got my first success! I convinced Winamp to notice an external change to the title tag of a file, without the modification time of the file being changed. Just what I wanted! There were still a couple of issues though so I kept working. I made some inconsequential change (like alerting the value of some variable), changed the title back to what it should be and tried to get Winamp to notice. Nothing. Of course I undid my change, back to what worked. Still, nothing. I banged my head of a wall and shouted a lot. To cut a long story short (in the middle of which most of what is below should actually appear) it turns out that this method works, once. It won’t work again on the same item until Winamp’s rescanned that file (rescanning actually fixes a lot of stuff, more of which later). Not ideal, but certainly workable. If I’d realised that immediately I may have just stopped and lived with it (I have Winamp set to rescan the entire collection periodically anyway). The thing is I didn’t immediately realise that’s what was happening (that is only due to my own incompetence) and so continued forging on, back to the version which “physically” moves the file around.

So I took my half working, when the Moon is shining right, script and put back the file movement. Store the meta info. Take the file, rename (move) it to a temporary name. Load it as a new item. Insert the item to the Media Library and delete the original. Go back the other way, adding the meta info at the last just before inserting the thing back to the Media Library. That works, consistently. It has a couple of problems that I’ll get to, but it does update the tags if they’ve been externally changed, and does so more than once on the same item. The astute reader may wonder the purpose of the whole middle section. Why is the copied file added to the Media Library, only to be removed again. The answer is I don’t know but it seems I have to add it to the library or the whole thing doesn’t work, even though that temporary item isn’t storing anything and doesn’t do anything. I’ve given up trying to figure out why this is…best guess it’s triggering something to update the database, or I’ve stared at it so much I’m being blind.

I mentioned above a couple of problems with the process, which still persisted. The big one was the year was appearing as 0000. Pass as to why, the only way to make it make sense I could find was to store the year from the item just before inserting it into the Media Library, then load the item from the library and set the year to the value just stored. I think that’s just weirdness and I’m ignoring it as a fixed bug ;-)

The other things that happen…if the lastplayed is blank it gets set to 1st January 1970 (that’s epoch in case you wonder why). That doesn’t really bother me, as that specific date can always be filtered on if need be and is hardly likely to show up in a played this week search. Finally the last modified and filetime fields get blanked. That last is annoying. If that didn’t happen then there wouldn’t really be a need to ever rescan the files run through the script. However, I don’t even seem to have any read access to filetime (or last modified), let alone write access, so there’s not a lot I can do. The lastmodified blanking is actually quite useful though because it means that if you do rescan Winamp will bother to read the tags from the file and that fixes everything, including the type=0 thing mentioned near the start of this epic.

The Solution

First a few caveats: This is barely tested, use at your own risk, blaa blaa. Tested using some mp3 files with Winamp 5.24 and activewinamp 1.0.0.1 (pulled from CVS). My brief testing shows that, as mentioned above, the type of the file is left blank, which means it won’t show up in the default view—include tracks with an empty type to fix that. lastupdate and filetime are also blanked. Playcount, rating and lastplayed all seem to be preserved, tags get updated to whatever’s contained in the file.

Installation

Grab and install ActiveWinamp then follow the instructions there to get the latest copy of gen_activewa.dll from CVS. Download the script and unzip it into ActiveWinamp’s script directory. Restart winamp and it’ll appear as a script under the Send to: menu.

Versions

Two versions of the script are included. The original, works only once between scans (RefreshTags_1time), version and the moves files around version (RefreshTags). If you just want to make sure Winamp will read the tags on rescan the first version is fine, but it’ll only show the first change you make between rescans (the scan should show up all subsequent changes though). If you want to refresh it more than once between scans use the second version. You’ll have to scan again to get filetime (or modified time) back but if you don’t care (and if you’re only doing this to files which have been in the library a while you might not) then you shouldn’t need to rescan.

Usage

Send the files to be updated to the script through the Send to: menu. The script will popup a little box to let you know it’s done. You have to refresh the Media Library view to see the changes (hitting the Clear Search button should do this).

Phew!