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
