Are we still stuck with just sqlite? Or will this be opening up to other/stronger databases?
Thanks .. looking like fun so far
A Q on database ..
Moderators: jiri, drakinite, Addon Administrators
A Q on database ..
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Re: A Q on database ..
We're still using sqlite.
How to make a debuglog - step 4b: viewtopic.php?f=30&t=86643
Re: A Q on database ..
Will that be expanded?
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Re: A Q on database ..
There aren't any plans for a change of this. I hope that any possible usecase would be covered by the current and future features of MM5. Feel free to let me know what you miss in the SQLite implementation though (here or over email)...
Jiri
Jiri
Re: A Q on database ..
Jiri .. first thanks for being open for discussion. And don't get me wrong I love MMW and like the looks of the new UI except that the graphics are flat like all things window8 .
I believe that MMW really needs expanding to "real" database and here are my major reasons ..
1) Stability. Yes I know that I am the only one that ever has a problem with MMW .. especially the DB. But this is a real problem. Just this morning MMW acted up again and I lost a couple hours of work. This is because the db is not saved for each transaction. It is one big file and updated at the end. I virtually never have any problems with say something using mySql ..
2) Multiuser. I want to share a single instance of the "db" with the family. Then my daughter could connect (using her own user) and add ratings or add tracks/vids etc. Wife .. the same. They could share their tracks or not. Also this would allow for the 'admin' to maybe hide some vids/tracks that you really don't want the kids to play. Think LOTR .. One mediaserver to rule them all
3) connectivity. I want to be able to easily access the db from external routines. Yes there is the connection object available but that is not entirely intuitive.
4) Accessibility. Along with that there is no easy way to work with the database directly. This is because of the .. crap my brain just froze .. you know the sorting page you use .. so only MMW can access the data (easily).
Don't get me wrong .. I'm not pulling a DrKeith <G> .. this isn't a deal killer .. but just like the 'service' should really becoming THE service .. the db needs to get out of the 'only one instance' mode. MMW is growing up and those old shoes are just too tight.
Thanks for listening ..
I believe that MMW really needs expanding to "real" database and here are my major reasons ..
1) Stability. Yes I know that I am the only one that ever has a problem with MMW .. especially the DB. But this is a real problem. Just this morning MMW acted up again and I lost a couple hours of work. This is because the db is not saved for each transaction. It is one big file and updated at the end. I virtually never have any problems with say something using mySql ..
2) Multiuser. I want to share a single instance of the "db" with the family. Then my daughter could connect (using her own user) and add ratings or add tracks/vids etc. Wife .. the same. They could share their tracks or not. Also this would allow for the 'admin' to maybe hide some vids/tracks that you really don't want the kids to play. Think LOTR .. One mediaserver to rule them all
3) connectivity. I want to be able to easily access the db from external routines. Yes there is the connection object available but that is not entirely intuitive.
4) Accessibility. Along with that there is no easy way to work with the database directly. This is because of the .. crap my brain just froze .. you know the sorting page you use .. so only MMW can access the data (easily).
Don't get me wrong .. I'm not pulling a DrKeith <G> .. this isn't a deal killer .. but just like the 'service' should really becoming THE service .. the db needs to get out of the 'only one instance' mode. MMW is growing up and those old shoes are just too tight.
Thanks for listening ..
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Re: A Q on database ..
dtsig, i can respond to item 4 ... here you can download sqlite plugin with our collation, so when you use editor with plugins support, you can use it and search,sort even with text fields.
How to make a debuglog - step 4b: viewtopic.php?f=30&t=86643
Re: A Q on database ..
Thanks PetrCBR. That does help ..
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Re: A Q on database ..
Thanks, good to know your thoughts about this, even though I have a different opinion is some aspects.
1) This really shouldn't happen, the DB is supposed to be very stable and secure. Please let me know more details, maybe a debug log could contain some useful info.
2) I'm afraid that it would add so much complexity, way more than most users expect and can even manage. I think that a more manageable approach is to have each DB stored locally per user, this way individual ratings can be handled. As for permissions - this can be handled by sharing (some parts of) a library over upnp, can't it?
3) What exactly you mean by external routines? I think that access through MM API works well.
Jiri
1) This really shouldn't happen, the DB is supposed to be very stable and secure. Please let me know more details, maybe a debug log could contain some useful info.
2) I'm afraid that it would add so much complexity, way more than most users expect and can even manage. I think that a more manageable approach is to have each DB stored locally per user, this way individual ratings can be handled. As for permissions - this can be handled by sharing (some parts of) a library over upnp, can't it?
3) What exactly you mean by external routines? I think that access through MM API works well.
Jiri
Re: A Q on database ..
Hi. Long time time!
Good to see that MM continues to march along into the future!
Regarding database/sqlite:
I agree with previous comment regarding multi user, I believe that many years ago when MM2 used access database, it was much easier to have multiple user sharing database, than since the change to sqlite.
As before, I believe the solution is to decouple the physical database from the app, to allow for any user supplied database backend (sqlite/mysql/MSsql/etc).
Like how KODI (previously xbmc) you can switch from the internal/local DB, to a remote MYSQL DB for media library.
Ever since then, I have KODI/MYSQL database running on NAS (linux based readynas), and a dozen different clients all accessing the shared media library.
I wish/hope that someday MM will eventually allow similar shared database implementation.
To Jiri, individual user/client profiles within a shared database can also be created to manage any type of individual ratings/play counts/etc, ie have both global play counts/ratings, and client/user specific ones.
Good to see that MM continues to march along into the future!
Regarding database/sqlite:
I agree with previous comment regarding multi user, I believe that many years ago when MM2 used access database, it was much easier to have multiple user sharing database, than since the change to sqlite.
As before, I believe the solution is to decouple the physical database from the app, to allow for any user supplied database backend (sqlite/mysql/MSsql/etc).
Like how KODI (previously xbmc) you can switch from the internal/local DB, to a remote MYSQL DB for media library.
Ever since then, I have KODI/MYSQL database running on NAS (linux based readynas), and a dozen different clients all accessing the shared media library.
I wish/hope that someday MM will eventually allow similar shared database implementation.
To Jiri, individual user/client profiles within a shared database can also be created to manage any type of individual ratings/play counts/etc, ie have both global play counts/ratings, and client/user specific ones.
New script: Last.FM Node Now with DJ Mode!
Last.fm + MediaMonkey = Scrobbler DJ!
Tag with MusicBrainz ~ Get Album Art!
Tweak the Monkey! ~ My Scripts Page
Last.fm + MediaMonkey = Scrobbler DJ!
Tag with MusicBrainz ~ Get Album Art!
Tweak the Monkey! ~ My Scripts Page
Re: A Q on database ..
+1 to that Teknojnky
Me and few other friends (one of them is database expert) are working on stable solution for MM and recently we made big progress when we developed bi-di communication for a friends client which can possibly used in MM. Simply said we used Combination of Direct MySQL Access on QNAP that share single MM Library (designated server MM) which is distributed/imported into Clients (MM clean Install). All DB is Handled using UNC path so it should be accessible on any Client accessing DB.
Other aspects like Playlists/collections/devices are per each client side. Unfortunately it is still in drawing board and far from test release but it is possible and can be made working.
Me and few other friends (one of them is database expert) are working on stable solution for MM and recently we made big progress when we developed bi-di communication for a friends client which can possibly used in MM. Simply said we used Combination of Direct MySQL Access on QNAP that share single MM Library (designated server MM) which is distributed/imported into Clients (MM clean Install). All DB is Handled using UNC path so it should be accessible on any Client accessing DB.
Other aspects like Playlists/collections/devices are per each client side. Unfortunately it is still in drawing board and far from test release but it is possible and can be made working.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts