2012/4/2 "Daniel Schürmann" <dasch...@gmx.de>
> Hi
>
> I have just tested QFile::map() on Windows XP. On Windows the file is
> automatically locked against writes from other processes when it is mapped
> by one process.
>
So this means that we cannot write to a file from an external process
while Mixxx has mmap'd it on Windows?
> -----
>
> I agree with Ilkka that we should pick a solid solution that covers also
> the rear use cases when a user uses Mixxx and a other allication with tag
> write capacity at the same time.
>
> Writing tags at Mixxx shutdown has some disadvantages in this case:
> * Mixxx always wins and may overwrites just changed tags with an earlier
> change done in Mixxx
>
Hmm, yes.
> * It will delay the Mixxx shut down unexpected
>
Yes.. I'm thinking it can't take too long to write tags though.
> * There my be issues with removable media
>
Good point!
> * There is a potential risk of data loss due to the (only theoretical ;-))
> case of Mixxx crash.
>
:) theoretically, of course, I think we should keep the list of tracks to
write metadata for in the database so we don't lose track of what has and
hasn't been modified relative to what's on disk.
Using an external process for taglib has the following advantages:
> * a own process reduces the risk of corrupting the track by a Mixxx error
> elsewhere.
> * A crash due to a corrupt file does not effect Mixxx itself. This was
> reported by a Clementine developer, can be found by Google and I might
> remember that we had a mixxx bug like that.
> * we can use the advantage of file locks, at least at win XP.
>
> I have the hope that we can continue using QFile::map(). It might be the
> best balance between performance and resource usage because its in the OS
> domain.
>
> If not, it will be just simlpe to change to an in-memory caching.
> QBuffer buf = flie.readAll()
> But its even bedder to have also the control to the allocated memory as
> Ilkka pointed out.
>
Yes, this will be unfortunate when the user loads a live-set or a CD-rip.
With mmap'ing we have the advantage of virtual memory paging out portions
of the file we aren't using.
> My favorite it to reuse the clementine-tagreader. It has a socket
> Interface to communicate with the host application and its based on taglib.
> It is an proved concept and already established.
> Using this we can easily reuse more clementine code like mass tagging and
> cover arts.
>
Hm, back to the old question of whether mass tagging belongs in Mixxx or
not :)
>
> (By the way: I fully agree with RJ, that Mixxx needs it own library and
> own GUI and that we have to be open for using Mixxx with any mediaplayer or
> track library tool.)
>
> Kind regard,
>
> Daniel
>
>
>
> -------- Original-Nachricht --------
> > Datum: Mon, 2 Apr 2012 06:33:38 +0300
> > Von: Ilkka Tuohela <ilkka.tuoh...@gmail.com>
> > An: Owen Williams <owilli...@mixxx.org>
> > CC: mixxx-devel@lists.sourceforge.net
> > Betreff: Re: [Mixxx-devel] Mixxx pissed me off today!
>
> >
> > As use cases go, I agree, nobody should be tagging tracks with exteral
> > programs while performing. On the other hand, changing the tag on mixxx
> screen
> > when you load the track is quite plausible, like in "Oh the artist tag
> is
> > wrong I'll fix it straight away!" use case. Some people also might use
> > itunes to look up songs while playing with mixxx, it's search has it's
> own
> > good points or someone might be more familiar with it. iTunes does not
> modify
> > tags itself unless you change something, so even this is not a problem as
> > such.
> >
> > I would even file a bug for easytag to fix the tag writing to use a
> > temporary file which is moved to correct name after updating tags, if
> they don't
> > already do this. I think they already do this anyway.
> >
> > Myself, I run with the music library owned by root to prevent anyone from
> > messing up the files and only chown them to myself when updating
> > information intentionally, enough issues with commercial programs
> helpfully writing
> > new tags or even corrupting the file to unreadable when I didn't ask
> them to
> > change it. When you have finished preparing your library, I can recommend
> > making editing it accidentally hard like this.
> >
> > About in-memory caching:
> >
> > I don't think the code to switch from mmap to in-memory caching would be
> > too hard to write, with configurable buffer size. It might be worth
> making a
> > branch with this to compare these two usage scenarios just to make sure.
> I
> > think it should use a fized size buffer for each deck, instead of trying
> > to allocate anything on the fly.
> >
> > Only problem I see with fized size in-memory buffers would be low-end
> > systems with limited memory, unless you calculate the buffer size and
> allocate
> > a buffer on-the-fly for each track: I would prefer here pre-allocated
> deck
> > buffers if this is done, but this may not work nicely if the laptop
> doesn't
> > have the memory available. Then again, 2 decks configured to play with
> > 128MB buffers each can be used to play about 11 minute long songs
> straight
> > from buffer and if the buffer size is configured in settings, it could be
> > adjusted to the expected maximum song length. The buffer size would
> normally
> > matter only to people who want to play a prepared full album mix, which
> of
> > course happens.
> >
> > As I said, I would prefer in-memory buffering over mmap, but then again
> > I'm always running on modern laptops with enough memory to give mixxx
> 2-3GB
> > without issues, and completely understand other use cases where this is
> not
> > possible or wanted.
> >
> > *hile*
> >
> > On 2 Apr 2012, at 06:05, Owen Williams wrote:
> >
> > > On Sun, 2012-04-01 at 22:29 -0400, Albert Santoni wrote:
> > >
> > >> This sounds pretty tricky. Would it simplify our lives if we dropped
> > >> mmapped I/O? (sorry Owen!)
> > >
> > > mmapped I/O was integral to preventing audio dropouts. Making that
> > > change resulted in the best improvement in sound performance. If we do
> > > have to drop mmapping, the replacement has to be an in-memory caching
> of
> > > tracks.
> > >
> > > That said, I still think it's incredibly unrealistic for users to be
> > > playing a track in Mixxx and also writing the tag of that track from
> > > another program. Can anyone imagine a scenario where, realistically,
> > > mixxx would be playing a track and something else would be writing that
> > > track?
> > >
> > > In-app, I think the best solution is delaying writes until shutdown /
> > > startup like RJ suggests. For users silly enough to use easytag or
> > > itunes while mixxx is running, they'll quickly learn not to do that :).
> > >
> > > owen
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > 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
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
>
> ------------------------------------------------------------------------------
> 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
