>SQLite is the ONLY working solution on the built-in server on the >Touch, so it has to be supported. > True - SQLite is the currently selected solution for embedded players.
Doesn't mean it's the best solution for full SBS, which is the only environment I really care about. >Now, the big question is: Is it more important to you to keep MySQL >than getting some new features than enhances your music >discovery/listening experience ? > Is that really a fair comparison - either MySQL or new features? I think it should only need a bit of dev support to keep it ticking over. The only people selecting MySQL are probably people who know what they are doing, or under instruction. Doesn't need Support or QA. It's a bit like MusicIP integration - it's still supported by SBS, even though the product doesn't exist any more. I think it's more important to have a rock-solid dependable music library, than new features. I would prefer performance, stability and perhaps some bug fixes ahead of some new features that could reduce performance, stability and introduce more bugs. Wasn't there some reports that large music libraries didn't work in tinySBS? I thought that could be indicating that SQLite struggles with big databases - memory issues perhaps on tinySBS. Does SQLite scale? >So on top of the question I asked earlier in the post, you also have to >question yourself if you want to keep using MySQL if neither TrackStat, >Custom Browse nor SQL Playlist is supported under MySQL ? > I will continue to go with bleeding edge until something I use frequently no longer works, at which point there needs to be a really good reason to upgrade further. I would normally be on latest dev trunk, but 7.6 doesn't work, so I'm currently on 7.5.1 trunk. If 7.6 continues to not work, I'm happy with what I currently have with 7.5.1 and plugins for that version. >IMHO, the ONLY reason that possibly can justify keeping MySQL is if we >believe that it will be hard/impossible to get good performance in >larger libraries with SQLite. Yes, that's the main thing. >All this focus on technical stuff >is silly, most people have their Squeezeboxes to play music, so that >should be the main focus. >So, let's put the focus on the music related stuff and select the path >that leads to most music related features. > What's actually happened/happening is the cut-down tinySBS is dictating functionality/development effort on full SBS. Because tinySBS memory constraints, there's been a lot of work on framework and existing features to keep a single code base, rather than have two separate solutions/applications that share features. No new features, just changes to existing features to make it work on tinySBS. Full SBS may suffer because some things need to be different for tiny SBS. As I see it, SQLite may reduce extendability for new architecture in full SBS. i.e. previous road-maps indicated that SBS could be split into separate processes. With SQLite, to get performance the DB has exclusive locking for the SBS process, so it can't be shared. There might be other limiting factors for any future plans to split the big SBS blob into more manageable smaller processes. There already seem to be issues with scanning - the exclusive lock has to be dropped, so that the user can browse/play music whilst the scanner is writing data to the DB. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
