Error: "Unknown object type" since switching to SD Card


A few years ago I created a music playing system that varies play frequency with rating and learns the ratings over time based on play and skip counts. It’s mostly run by smart playlists in iTunes, but I wrote an Applescript to update the ratings and clear play and skip counts.

The new development:

Recently bought a Macbook Air and moved my music library to a 256GB SD card and will often get an error message stating “Unknown object type” partway through processing all the songs that need updating. Note that this didn’t occur during the brief period with the Air but before the SD card (music was on an external hard drive) so that seems to be the crucial change. Not sure if I ever got this before the switch as errors were so rare I can’t really recall any, let alone the specifics.

Technical details:

iTunes 12.01.26
OS X 10.10
2012 Macbook Air 4 GB

I stripped my script down as much as possible while still getting the error:

tell application "iTunes"
	set ratingVal to 40
	if ((exists user playlist "WSP 2 stars?") and ((count tracks) of user playlist "WSP 2 stars?" is not 0)) then
		set input to get every track of user playlist "WSP 2 stars?"
		if (input is not {}) then
			repeat with theTrack in input
				-- set rating
				set rating of theTrack to ratingVal
				-- clear counts				
				set played count of theTrack to 0
				set skipped count of theTrack to 0
			end repeat
		end if
	end if
end tell

Is the slower access time of the SD card to blame? If so, is there anything that can be done about it? Thanks a lot.

I am rather ignorant of the fine points, but have a possible theory. What if in the process of updating the fields the track no longer satisfies the smart playlist’s criteria so it is removed, leading to an invalid object. If the script is fast enough, it would beat the playlist update and the error wouldn’t be encountered. I didn’t consider this before because I was envisioning the list of tracks as independent from the smart playlist once you’d stored them. Perhaps that is in fact how it works and my theory is nonsense.

Anyhow, I implemented a workaround for the moment, using dumb playlists as a buffer for the tracks and verifying the changes before removing them. If it still fails once in a while and I have to run the script a couple times to get it to finish, that’s no big deal, as long as it’s not messing up the data like it did before with partial changes.

Fingers crossed.

That appears to have remedied the error. Now it’s a question of finding a more elegant way to accomplish the smart playlist buffering.

Time for a more specific thread with that query, methinks, given this one didn’t get any responses.