>No, sorry I wasn't clear. This is only in SQLite and the nightlies. > Ah good, I can still update 7.4/trunk then! ;-)
>> Is MusicIP interraction still supported? I think I read somewhere >> that it didn't work in the noweb-sqlite branch? > >MIP should still work as before, although I haven't tested it in the >past few weeks. > Great - I'll try it out. >> I guess that MySQL support is still missing? Any adeas of a >> timeline for that? Until it is supported, or all plugins have been >> converted, I can't use this as my day-to-day server, and have to run >> SQLite version in parallel for beta testing. > >But please don't avoid SQLite if your only concern is performance. > I have a secondary server set up using noweb-sqlite. Will try comparing performance when I get the same library content in both servers. I will need to disable plugins in my main server for memory/speed performance comparisons. It's not just performance - I rely on some third-party plugins that won't work with SQLite. >It performs very well in my experience. And yes my scans >are consistently faster than in 7.3.3. I meant to post some benchmarks >on the wiki page, will do that a bit later. > I thought the compiled scanner were the main reason for faster scanning. Other people have posted that performance is worse. Better/more important performance tests will be to run searches, browse album lists, etc. I'm not too bothered about scanning performance (or I wasn't when it was a separate process). >If you Google for SQLite GUI you should find some. There is even one >that is a Firefox plugin. > I tried some; didn't work too well. I saw the Firefox plugin one, and saw it wasn't maintained any more. Seemed a bit bizzarre. I guess it's because firefox bookmarks used to be stored in a SQLite DB (but the format has changed?) >Not sure about this specific case but this is exactly the kind of bug >I want to fix. Some such as changing genres or years are already >handled. This is one of the areas where I really need people's help, >trying common use cases for changing tags. > I've raised several bugs about this sort of issue in the past, so I can try them out to see if they are now fixed. Some may require schema changes. >Right now it's always enabled for Mac and Linux with local files. I >plan to make it a pref though. There is a built-in delay to handle >exactly the situation you describe. The rescan kicks off 15 seconds >after the last event is received. > Great. Not turned on for Windows though? Is there a way to enable it? >This needs testing to see if there is any impact. If it's a problem we >can easily have the auto-rescan kick off a new process. In-process is >supported for low-memory environments mostly. Okay, will try it out. I'm fine with it being in-process for the full rescan (wipe) case, because I normally don't play local music until it's finished (typically full-rescan overnight). Playing music when scanning can mess up library, as playing a song invokes the scanner too. i.e. because it may not yet have merged various artists, etc. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
