Hi Guys, Thanks for filling me in. I absolutely understand and respect the decision to not write to file if there was a risk of damaging a users media library.
So here's my thoughts. "In general I have the opinion that Mixxx is not the right application to beautify the track library. " If Mixxx is not writing to metadata - the data should not be editable AT ALL. Its is misleading. No questions. Take the feature out, stop trying to be clever. Just accept that Mixxx is not the place for this. Users will then understand they should use another tool for this process. "Mixxx is a nice interface for tag editing, though, so it might be worth pushing up the importance of that bug." I agree that Mixxx is indeed a nice interface for tag editing, which is why I chose to use it. Clearly there are two issues here that need resolving. 1. Allowing the data to be editable results in data stored in the database and not in the files. Once the issue of how to inform the user of unsaved data (that's slightly unfair because I know data is "saved"). Even a text colour change (red or light grey) to indicate data not stored in files would be better than nothing. Users understandably would start to ask "Why is some of my library data red?" which can be answered - "its not saved in the audio files" - the obvious reply will be "well how can I write it to my files?" 2. Write the data to the files - this is clearly a challenge. I do NOT believe you can offer 1, without 2. Thanks again for some great feedback, I'll do my best to give some constructive suggestions in the future when I have a better understanding of the challenge. thanks Keith On 31 March 2012 09: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 -- keithsalisb...@gmail.com ------------------------------------------------------------------------------ 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
