Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sarcanon]

Hello.

Might anyone know of a way to query the library database without using the HTTP API? Is the database perhaps in a SQLite database or other compatible file that can be accessed via third party SQL query apps like DB Browser?

Thank you.

[zybex]

No, AFAIK as far as I know it's a custom DB format created by JRiver.

[The Big Labinski]

I've never heard about a database format called afaik?

[voodoo5_6k]

I've never heard about a database format called afaik?

AFAIK = As far as I know

[sarcanon]

No, AFAIK as far as I know it's a custom DB format created by JRiver.

Really? With a really solid and performant open source embedded database like SQLite, and no doubt others I'm not aware of, it seems like a rather odd design decision to roll your own solution.

Anyone know where can I make a feature request to open up the database through some sort of API, preferably read/write?

Thank you!

[JimH]

zybex The Big Labinski is pulling your leg.

Take a look at MCWS here:
https://wiki.jriver.com/index.php/DevZone

[Matt]

We're really proud of our DB.  It is open with MCWS.

https://www.jriver.com/speed.html

[zybex]

zybex is pulling your leg.

Not at all Sarcanon asked for a non-HTML interface like SQL, and MCWS is an HTTP REST API. (talk about acronym abuse...)

[zybex]

We're really proud of our DB.  It is open with MCWS.

https://www.jriver.com/speed.html

Fast indeed, which is what matters There are however some drawbacks and areas of improvement:
- fully in memory DB, problematic for huge libraries on cheap machines (but if you have a huge library you should also be able to afford 16/32/64GB RAM as needed)
- changing the length of text on any field requires a full rewrite of the corresponding DB file; ie, adding Lyrics to a file at the top of the collection will trigger a full rewrite of the "field (Lyrics).jmd" file, which can have tens/hundreds MB. It may require recompressing the data with ZLib, depending on how you are doing it in memory. This is not so bad today, with SSD drives, but it's still an inefficiency.
- very poor (ie, none) data redundancy and recovery capability. Any DB corruption cannot be recovered without restoring a backup
- relational fields feature is grafted on top of the DB, which doesn't natively support it. This sometimes is the source of data inconsistencies and makes it hard to add new features that leverage the DB
- Lack of indexes (except the ones you create in-memory when loading the DB). More indexes would make common uses of the GroupQuery functions much faster on large DBs

I agree that speed is the single most important factor. For very large DBs it's likely that MySQL/MSSQL DBs offer higher query performance when configured with appropriate indexes and relational structure; however, it's true that the vast majority of MediaCenter libraries out there are 'small' (ie, less than 1M records), so the gains would not be visible for most people. It would however increase interoperability, and possibly lead to the creation of more 3rd party tools (including migration tools, which some people ask for)

[JimH]

Fast indeed, which is what matters There are however some drawbacks and areas of improvement:
- fully in memory DB, problematic for huge libraries on cheap machines (but if you have a huge library you should also be able to afford 16/32/64GB RAM as needed)
- changing the length of text on any field requires a full rewrite of the corresponding DB file; ie, adding Lyrics to a file at the top of the collection will trigger a full rewrite of the "field (Lyrics).jmd" file, which can have tens/hundreds MB. It may require recompressing the data with ZLib, depending on how you are doing it in memory. This is not so bad today, with SSD drives, but it's still an inefficiency.
- very poor (ie, none) data redundancy and recovery capability. Any DB corruption cannot be recovered without restoring a backup
- relational fields feature is grafted on top of the DB, which doesn't natively support it. This sometimes is the source of data inconsistencies and makes it hard to add new features that leverage the DB
- Lack of indexes (except the ones you create in-memory when loading the DB). More indexes would make common uses of the GroupQuery functions much faster on large DBs

What do you want to fix that stuff?

I agree that speed is the single most important factor. For very large DBs it's likely that MySQL/MSSQL DBs offer higher query performance when configured with appropriate indexes and relational structure;

Prove it.

[Wheaten]

Prove it?
Thats a tough one as we can't run metrics on it, since it is not accessible outside JRiver.
But indeed the priority for JRiver should be speed, reliability and availability on the different platforms, which seems to do a pretty good job so far.
Will the benefits of changing justify the costs as dB crashes doesn't seem a hot topic here.