My mistake, I just looked at #728197 and if I understand correctly it is a file access / lock issue.
On Sat, 2012-03-31 at 22:46 -0400, RJ Ryan wrote: > We actually use TagLib for all of our metadata processing needs -- we > didn't roll metadata writing ourselves or anything like that. > > > On Sat, Mar 31, 2012 at 10:18 PM, Scott <nappingcrac...@gmail.com> > wrote: > This sounds a bit like NIH (not invented here) syndrome. > > I suggest using id3lib to do the actual file manipulation and > simply > hook Mixxx's front end into that API. This would work for at > least ID3v1 > and ID3v2 tags. > > id3lib http://id3lib.sourceforge.net/ has been around for a > while and is > used by many tagger / player programs. EasyTAG uses it, and > I've used > that program without problems for years on tens of thousands > of files at > a time. > > This would leave the quality control to a group focused > specifically on > manipulating audio file tags and metadata. > > -Scott > > On Sat, 2012-03-31 at 22:40 +0100, Adam Davison wrote: > > Hi, > > > > I think Albert's general point was more that if you have any > memory > > corruption anywhere in Mixxx, then the results of our write > to the > > file are undefined. Even if we fix this specific memory > corruption bug > > then we have no way to guarantee there aren't more lurking. > In fact I > > could probably guarantee you that there are memory > corruption bugs > > lurking in code the size of Mixxx + all the libraries living > in our > > process space. > > > > One safe way to do it perhaps would be to have a very small > helper > > program which handled the writing in a different process. > > > > Adam > > > > On 31 March 2012 18:54, Ilkka Tuohela > <ilkka.tuoh...@gmail.com> wrote: > > > > > > Maybe I'm asking the obvious, but why wouldn't following > process work just fine: > > > > > > - Store new tags to database fields > > > - Make a copy of the file on disk to temporary file, > original being still mmaped or not doesn't matter > > > - Write tag changes to the temporary file > > > - If writing temporary file was successful (disk space was > enough etc), unlink old file and rename new file to original > name > > > - If writing temporary file was not successful, remove > temporary file and report error, maybe revert database fields? > > > > > > At least on unix-like systems, the mmap will hold a > reference pointing to the original deleted file, and the > changes to tags can't affect it, preventing corruption. This > will use extra bytes from disk for all rewritten files (mmaped > bytes + new file with new tags) as long as the mmap FD is > open, but since we don't hold hundreds of files open in > player, the extra disk space used should not be an issue and > is released anyway on fs level when the FD is closed by mixxx > (song has been played). > > > > > > Additionally, if we wish to show the updated tags in > decks, I think the tags should be and are based on database > entries not file tags and should reflect the current info > correctly (as long as there is a slot to update the details in > player on the fly). > > > > > > I have no idea if this works similarly on windows > filesystems though, but I think so. > > > > > > *hile* > > > > > > On 31 Mar 2012, at 18:13, Owen Williams wrote: > > > > > >> I did develop an initial crappy workaround that prevents > many of the > > >> memory-corruption situations. Basically, if Mixxx can > know for sure > > >> that the music file is not open, it's safe to update the > metadata. The > > >> trick is figuring out if in fact that file is open or > not. > > >> > > >> I don't believe there's any risk in corrupting the file > on disk. The > > >> corruption I experienced was only in terms of playback -- > still a big > > >> problem because it would cause static during sets. > > >> > > >> Mixxx is a nice interface for tag editing, though, so it > might be worth > > >> pushing up the importance of that bug. > > >> > > >> (one solution might be queuing the metadata update in the > file reader > > >> object itself, and then writing the data in the > destructor. Is it safe > > >> to assume only one file object per file, though?) > > >> > > >> Owen > > >> > > >> > > >> On Sat, 2012-03-31 at 10:38 -0400, Albert Santoni wrote: > > >>> Hi Keith, > > >>> > > >>> I'm sorry you had a crappy experience with this - Our > intention was to > > >>> reduce the risk of data loss.... which is the opposite > of what > > >>> happened to you. > > >>> > > >>> Mixxx did not write write metadata to any music files > until 1.9 > > >>> because we were concerned that we didn't have the > quality control in > > >>> place to ensure we would never ship a library-destroying > bug. Just > > >>> imagine if we had a bug that caused your MP3s to get > corrupted... > > >>> > > >>> And it turns out this fear wasn't totally unfounded. > After 1.9 > > >>> shipped, Owen tracked down a subtle memory corruption > bug related to > > >>> Mixxx writing to MP3s, and although there were no > reports of corrupt > > >>> files, file writing and memory corruption are not a > great combination. > > >>> (You might be able to make an argument that Mixxx is > more susceptible > > >>> to heap corruption programming errors which may not > affect the actual > > >>> file writing itself if it's done on the stack. I'm sure > the > > >>> TrackInfoObjects are kept on the heap though, so maybe > worst case you > > >>> could just end up with corrupt metadata. But never say > never...) > > >>> > > >>> As Daniel pointed, it was due to bug #728197 that we > disabled metadata > > >>> writing for Mixxx 1.10.0 and made a quick 1.9.2 release. > > >>> > > >>> If you have any suggestions on how we can communicate > that metadata > > >>> isn't written or want to work on #728197, you know how > to get in > > >>> touch... :) > > >>> > > >>> Thanks, > > >>> Albert > > >>> > > >>> > > >>> On Sat, Mar 31, 2012 at 4:32 AM, > keithsalisb...@gmail.com > > >>> <keithsalisb...@gmail.com> wrote: > > >>>> Sorry guys, normally I wouldn't say this, but something > happened today > > >>>> which I really don't understand why this choice has > been made, maybe > > >>>> someone can explain. > > >>>> > > >>>> So in the last week or so, I've spent many hours > tweaking the metadata > > >>>> in my dj library, sorting out track titles, artists, > labels, keys, > > >>>> bpms all sorts of goodness which makes a record box > more than just a > > >>>> bunch of files. > > >>>> > > >>>> It was my assumption all this goodness was being baked > into the files. > > >>>> > > >>>> Yesterday as part of building a new version I moved > my .mixxx config, > > >>>> and associated database etc out the way to create a new > one. > > >>>> > > >>>> And here it is, to my surprise and quite honestly my > shock, my files > > >>>> we ALL back to their tatty messed up disorganised state > - ALL my time > > >>>> and effort had been reverted. > > >>>> > > >>>> Now you'll notice I was smart enough to backup my data > before creating > > >>>> a new database, so I've not really lost anything, > however I AM upset > > >>>> that this happened. I would expect more from Mixxx. I > actually trusted > > >>>> Mixxx more than Rhythmbox or those other media browsers > to do the > > >>>> right thing by my files. > > >>>> > > >>>> So what's the deal here - I can understand a concern > allowing users to > > >>>> edit their files - sure - but there should be a > config/preferences to > > >>>> allow me to choose. And more over, I should be made > aware that all > > >>>> this goodness is not really in my files. Somehow. > > >>>> > > >>>> My point is, I'm a power user, but I'm sure many users > out there have > > >>>> edited their files believing they're updating the > files, and only when > > >>>> they change computers, or rebuild their computer or > whatever, that > > >>>> they find out all that data is lost. > > >>>> > > >>>> Thoughts? > > >>>> > > >>>> Keith > > >>>> > > >>>> > > ------------------------------------------------------------------------------ > > >>>> This SF email is sponsosred by: > > >>>> Try Windows Azure free for 90 days Click Here > > >>>> http://p.sf.net/sfu/sfd2d-msazure > > >>>> _______________________________________________ > > >>>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today > > >>>> http://mixxx.org > > >>>> > > >>>> > > >>>> Mixxx-devel mailing list > > >>>> Mixxx-devel@lists.sourceforge.net > > >>>> > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------------ > > >> This SF email is sponsosred by: > > >> Try Windows Azure free for 90 days Click Here > > >> http://p.sf.net/sfu/sfd2d-msazure > > >> _______________________________________________ > > >> Get Mixxx, the #1 Free MP3 DJ Mixing software Today > > >> http://mixxx.org > > >> > > >> > > >> Mixxx-devel mailing list > > >> Mixxx-devel@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > > This SF email is sponsosred by: > > > Try Windows Azure free for 90 days Click Here > > > http://p.sf.net/sfu/sfd2d-msazure > > > _______________________________________________ > > > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > > > http://mixxx.org > > > > > > > > > Mixxx-devel mailing list > > > Mixxx-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > > http://mixxx.org > > > > > > Mixxx-devel mailing list > > Mixxx-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel