Library completely messed up

Thank you for getting in touch. This is indeed troubling.

My first thoughts after reading this...

Ruby... Odd that Ruby has come into play somehow, TuneSpan does not use Ruby.

All Tracks? Because of how TuneSpan works, it is highly unlikely that it could possibly affect track info for tracks not spanned. The actual iTunes library file is never touched. If interested it may be good for you to take a look at the "How does TuneSpan work?" section of the TuneSpan Help (http://tunespan.com/help.html). Just so that you also understand TuneSpan. Briefly, it does not directly change any track locations in iTunes. Any time iTunes changes a track location, it did so itself, and modified its own database. Of course, with some coercion from TuneSpan, but still, it would be impossible for TuneSpan to coerce iTunes into modifying tracks you have not spanned.

iTunes 10... TuneSpan 0.9.2.2 does not support full spanning (and probably not full restoring) for iTunes 10 (due to a minor change on the part of iTunes). The big 0.9.3 update I have been working on will the able to fully span tracks with iTunes 10 and previous versions. But even still, the result should have been at worst dependently restored tracks, not all this.

Time Machine... So happy you have Time Machine installed, I highly recommend this for all users of this beta software.

So basically, the pieces of this puzzle don't seem to fit together at first glance, but that is not to say this was not caused by TuneSpan. We need to investigate more. If it is not too late, before you restore everything, could you send me your iTunes Music Library.xml file? Also TuneSpan's SpanRestoreHistory.tscddb in ~/Application Support/TuneSpan could have some hints.

Also, some info about the tracks you had spanned that you were restoring could be helpful. Were the tracks fully or dependently spanned? Even though the iTunes database got messed up, are the tracks back in their locations you expected them to be? What kind of drive were the tracks spanned to? What is formatted HFS+? Disk formatting could be an issue if the format does not support symbolic links.

I am very curious to see the locations that TuneSpan has stored. The TuneSpan database keeps a record of Original location, iTunes location, Span location and Previous location, so there should be some hints in there.

I will continue to think more about this issue and how TuneSpan could have possibly been the culprit.

Also, if you would like to talk about this issue in a quicker way, I would be willing to IM or even talk on the phone (if you are in the States) with you about the situation. Let me know if you would like to go this route...

Hi Pico,

thanks for your fast answer. Ok, it's not 100% of all tracks pointing there but a big lot of them and yeah, the most of them haven`t been spanned. The funny thing was after recovery, Tunespan told me that 3 tv-shows and one song were dependently restored, but they where. Ok, after restoring I found my library devastated, before it was ok. I don't know if something is lost, but I guess not all has been restored to its original location, since the folder had 160GB on the external HD and now only 130GB are missing on the internal. The external disk is hfs+ formatted.

I understand that Tunespan does not touch the library, but I find no other cause. Maybe there is an issue together with iTunes 10 with the symbolic links tunespan creates. But it comes to my mind that some weeks ago, I wanted to sync my iPhone and one track couldn't be synced. It was pointing to somewhere in the Ruby folder as well. But a check over the rest of the library showed that there was nothing else wrong. I don't know if this was after spanning some tracks. So maybe it's connected deeper somewhere in SL10.6.4?

I spanned all the tracks with an earlier iTunes version, don't know which one, so I guess they were all fully spanned. That may have been an issue after updating to iTunes 10. So I guess my fault, since I did not consider to recover all tracks before updating iTunes.

I am uploading the library xml to http://philipp.ochtendung.com/SpanRes...

Since I am in Germany talking on phone is not such a great idea I guess. If you have further questions you find me on Facebook : Philipp Ochtendung should be a unique name. Or you can get me on ICQ: 467524130 write something so i know who you are. But maybe more about tomorrow evening. Maybe around 6pm GMT. It's a bit too late by now.

Regards,

Philipp

I have downloaded your XML file and am taking a look now. But I am getting a 404 Not Found on the SpanRestoreHistory.tsccdb

After looking in the XML library file, I see that iTunes thinks that lots of files are in fact located in that Ruby system folder. Oddly, they are not actually all the same locations, but many sub different sub files of the Ruby.framework, very odd.

Also, I see that there are some MPEG-4 video files as well as AAC audio files that has the Ruby.framework location, among other file kinds. Back to how TuneSpan works... full spans are only attempted on MP3 audio files, all AAC files are "dependently spanned" meaning that the location in iTunes is NEVER actually modified. For these tracks, symbolic links are created automatically by TuneSpan Helper when iTunes launches. So when these tracks are restored, they are simply placed back in their original location. This leads me to be further confused by the issue, and is another hint that TuneSpan may not be the culprit.

I am not trying to say that TuneSpan is for sure not responsible, and I am also not saying that I am not interested in finding the root of the issue. Regardless of the original culprit, this is a serious issue and I do want to do my best to help fine the source of the problem.

Taking a look at the XML library has given me some hints, getting my hand on the TuneSpan database will further give some hints to when the location was changed, and if TuneSpan was part of the reason.

The database should now be in its place. Maybe we can report this as a bug to apple. Could be there's something wrong in iTunes. The only thing is, it just happend immediately after using Tunespan and I thought that might be helpful to post before someone else runs into the same issue without having Timemachine.

Regards,

Philipp

Just downloaded your TuneSpan database, gonna take a closer look now.

I for one am happy you posted the issue on here and let me and other users know this happened. Having all weird situations documented is very important. If this same thing happens for another user, it will definitely be good that we have this thread started.

The issue very well could be in iTunes, but I am not confident yet in saying that I know precisely what is going on here.

I'll get back when I learn more info.

Another note about TuneSpan behavior...

TuneSpan never changes any files names. The original file name it had before using TuneSpan is the filename that TuneSpan will always use, there is not one line of code that will ever change a files name. (TuneSpan will not overwrite or rename any file. If a file with the same name exists where TuneSpan is trying to move it, TuneSpan will just skip those files.)

So even if somehow TuneSpan was the one that got this Ruby.framework path, it would have appended the filename at the end of the path, which did not happen.

One thing that I have not ruled out is that some Symbolic Links were not created properly and somehow made iTunes change the location, but I have no actual evidence of this. But also, if this were the case, I do not understand how any of your non-MP3 tracks locations would have been affected since the method used by TuneSpan cannot get iTunes to learn a new location for non-MP3 tracks.

Just wanting to document my thoughts on the issue, no conclusions yet.

More notes:

Number of tracks in your iTunes Music Library.xml with locations in Ruby.framework: 2685

Number of track in your TuneSpan database with locations in Ruby.framework: 1642

So that is 1043 tracks whose locations were changed that were never spanned, something that I don't believe TuneSpan could have done.

Have you navigated to this Ruby.framework and seen if it is riddled with your media files? If somehow the actual files were moved there?

But again, the paths listed are some files actual path, such as "/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/doc/net-sftp-1.1.1/ri/URI/SFTP/new-c.yaml"

not a directory with the original filename appended on it how TuneSpan does. And again, if for some reason TuneSpan thought the file was named "new-c.yaml" and tried to move it to the directory "/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/doc/net-sftp-1.1.1/ri/URI/SFTP/"

The move would have failed since a file with the same name already exists, and this failure would have been listed in the TuneSpan results window.

I am interested in the actual location of your media files (not where iTunes thinks they are). I know it can be hard to track down with all the nested folder, etc of the iTunes organization, but if you did lose and files in the situation (possibly because the locations got messed up in iTunes for some other reason), it is something that TuneSpan could have been involved with and something that I would want to make sure could not happen.

I have written TuneSpan with the intention that whatever way the TuneSpan or iTunes databases could be messed up, that the actual files should never be removed. The only case that I know of that a file could be removed when using TuneSpan is if there is a serious issue with a drive involved. Because of how TuneSpan moves files with the [[NSFileManager defaultManager] moveItemAtPath: currentPathToItem toPath: newPathToItem error: &moveItemError]; method, OS X is responsible for removing the original file if and only if the file was successfully created in the new location. I personally encountered an issue with a faulty drive where the system thought that the file was successfully moved, but it was not and some files were lost, sadly there is no catch that I can write to detect it when the drive it self is not responding correctly. Also, any code in TuneSpan that removes anything is strictly for folders that are empty and symbolic links.

Just checking back in on this issue.

Did you discover anything new and/or get your library back in order?

Hi Pico,

I brought my library back in order by hand. Browsed through the library file with a texteditor if anything is at crude locations, but by now everything seems ok.

I did not use tunespan anymore since then. Do you have a new version, maybe I'll give it a new try. Since Timemachine is running nothing should be going bad.

Thanks for your interest and help in this issue.

Thanks for letting me know how things are going. I am glad everything is back in order.

About a new version, yes! TuneSpan 0.9.3 has been released and 0.9.3.1 is not far off. TuneSpan 0.9.3 brings full spanning support to iTunes 10 as well as big backend and user interface changes to the TuneSpan application.

Just coming back to mark this issue as solved.