MySQL Support

[rsvg 14]

22 minutes ago, roaku said:

There's reply confusion because someone is complaining about something unrelated to the main discussion topic.

What? I don't see any confusion. We're all talking about Emby allowing us, it's paying users to store our data in MySQL, or a similar, non-hobbled, SQL based relational database right? Then I pointed out how that's been a common paradigm for 20 years. Definitely the main discussion topic. 

[gnufreak 3]

No roaku@, there's a comprehension deficiency, resulting from selective reading, as correctly pointed out by koopa8840@.

Anyway, I don't expect much here from people attacking valid points without taking the time to understand them first.

Edited August 2, 2021 by gnufreak

[roaku 795]

Good luck everybody.

[rsvg 14]

4 hours ago, gnufreak said:

No roaku@, there's a comprehension deficiency, resulting from selective reading, as correctly pointed out by koopa8840@.

Anyway, I don't expect much here from people attacking valid points without taking the time to understand them first.

Wrong again, I'm pretty sure we easily comprehend that the developers are choosing to de-prioritize the feature. We just disagree with that, and will continue to point out the benefits of the "feature" whether the devs, or their simple forum groupies agree with it.
 

1 hour ago, roaku said:

Good luck everybody.

Yeah, apparently we're going to need it with people so willing to ignore what is basically a configuration option.

[gnufreak 3]

@rsvg - I think you're responding to the wrong person - my comment was aimed at roaku@ throwing "confusion" around for no reason.

[roaku 795]

lol there's no confusion what was i thinking

[gnufreak 3]

Quote

I want a beefier DB like most people on this thread, but the argument you are trying to make isn't valid

pir8radio@ The fact that you didn't read or understand it doesn't make it invalid but that's been already pointed out by koopa8840@
Also, I really am not seeking validation from someone who calls people advocating using an RDBMS in 2021 'hard-core'

Quote

But the sticker doesn't say anything about this car not being able to turn into an airplane

Oh, the arrogance of people who have no clue and yet they try to explain.

There are certain usual features that a car is expected to be able to do. Flying isn't one of them but getting into gear and starting to move is.
Better luck next time.

[pir8radio 1292]

Wow guys,  I mean to each their own..     I was just being polite.   Pointing out that 30 out of 30k users isn't going to get this feature built into emby because you say its super super important, then start talking down to everyone (last part really doesn't help your case).    You guys continue to be Karen's, the rest of us that want another DB well, we will wait until there is a technical requirement for it, or all of the sudden my parents that have an emby server,  and the other 30k people like my parents, decide they want a different database that they have no idea is even running in the background or exists, hops on here and requests the feature.        A total of 8 posts and 42 posts from these noobs that think they can come in here and act like fools just because they discovered emby.      I mean, I've already turned off notifications on this post so i wouldn't even bother with a response, but you still will respond..   not worth any of our time addressing these temper tantrums. 

Edited August 8, 2021 by pir8radio

[PFTKev 2]

+1 for external database support. I prefer the speed and flexibility that this option supports. The majority of people running these are power users or higher and want to take best practices from the business world and replicate them to their home setups. Regardless, I do believe the feature request section needs counters to allow voting to occur so that priority among your userbase can actually be measured rather than just making assumptions. The highly negative tone and confrontational nature of this thread will keep many from posting here preventing the use of this thread from serving as any sort of measurement of interest for this feature.

[PFTKev 2]

15 minutes ago, PFTKev said:

Regardless, I do believe the feature request section needs counters to allow voting to occur so that priority among your userbase can actually be measured rather than just making assumptions. 

Apologies, it was not obvious that the "likes" on the thread were being used as a method of tracking support.

Edited October 22, 2021 by PFTKev

[softworkz 3335]

10 minutes ago, PFTKev said:

Apologies, it was not obvious that the "likes" on the thread were being used as a method of tracking support.

User feedback in the forums is always taken seriously and many advancements that are made are based on it.

27 minutes ago, PFTKev said:

Regardless, I do believe the feature request section needs counters to allow voting to occur

As said above, recognizing trends from forum feedback is what we do already, but real "voting" is something different and a lot more complicated as it might seem.
I mean - how should this "voting" work"?  Have a single button at each conversation for "Yes I want this"? How do you get to know which users don't want this? Have a second button "No, I don't need this"? That would not be fair, because primarily those users would come to a thread who want it - not much of those users who don't need it.

Next, you could say: well, then put up that question at a neutral place where everybody can find it. But then there are still two problems remaining:

1. Most users do not regularly visit the forums, but that shouldn't mean that their requirements count less than from those who do

2. The question would still be wrong. When you ask: "Yes, add support for externals dbs" vs. "No, I don't need it", many would vote for "yes" just because it might sound good to them, even they'd never use it.

A much more realistic question would be something like:

"What do you want us to work on during the next few months?" => Options A, B, C, D, E, F

I won't close this by making any "assumptions" as you called it. Just a question: what do you think at which position the "External DB Support" feature would rank in such a voting?

[softworkz 3335]

I don't want to say it will never come. I want to say that when it comes, it won't come because it would be the request of a majority but for other reasons instead.

We have many new things in the pipeline and one good news I can tell is that large parts are already done in a way that alternative database support can be added easily. Changing the core Emby db access is still quite a huge task. Sooner or later there will come something (maybe one big or several smaller pressing reasons) that will pull the trigger on this. Though I can't predict  when that might happen. 

[gnufreak 3]

I don't want to say it won't come. I want to say it will when Emby gets devs who are familiar with something more than their own single-machine "test environment", which is most likely... never.

Until then, good luck with more meaningless BS posts of immature devs incapable of reading with comprehension and taking personal offence

Nope, I'm not even mad, I've worked around this idiotic design issue for my environment, I'm just taking a piss of fisher-price developers.

[rsvg 14]

On 8/7/2021 at 7:59 PM, pir8radio said:

Wow guys,  I mean to each their own..     I was just being polite.   Pointing out that 30 out of 30k users isn't going to get this feature built into emby because you say its super super important, then start talking down to everyone (last part really doesn't help your case).    You guys continue to be Karen's, the rest of us that want another DB well, we will wait until there is a technical requirement for it, or all of the sudden my parents that have an emby server,  and the other 30k people like my parents, decide they want a different database that they have no idea is even running in the background or exists, hops on here and requests the feature.        A total of 8 posts and 42 posts from these noobs that think they can come in here and act like fools just because they discovered emby.      I mean, I've already turned off notifications on this post so i wouldn't even bother with a response, but you still will respond..   not worth any of our time addressing these temper tantrums. 

Dude, these are harsh words coming from a forum groupie. You need to make up your mind, are we a very limited number of users requesting an advanced feature, or are we noobs? Noobs are the basic posts you spend your friday nights responding to so you can build up your stellar reputation lol. At least the devs realize the value of the request and respond like intelligent professionals and acknowledge their users requests. You're just a sad super fan, get lost. But hey, you won't see this because you muted notifications right?

I actually already forgot about this whole thing until i got a notification today. I also found a workaround ¯\_(ツ)_/¯

keep on keepin on, thanks softworkz

[softworkz 3335]

2 hours ago, gnufreak said:

I don't want to say it won't come. I want to say it will when Emby gets devs who are familiar with something more than their own single-machine "test environment", which is most likely... never.

Until then, good luck with more meaningless BS posts of immature devs incapable of reading with comprehension and taking personal offence

Nope, I'm not even mad, I've worked around this idiotic design issue for my environment, I'm just taking a piss of fisher-price developers.

You are funny. You're going crazy about getting a feature from a software, that you are discrediting in a way, that no sane person who would be sharing the same view and opinion, would ever use that software, neither bother to post in the forums of that software at all.

Edited October 23, 2021 by softworkz

[GrimReaper 3293]

12 hours ago, rsvg said:

Dude, these are harsh words coming from a forum groupie. You need to make up your mind, are we a very limited number of users requesting an advanced feature, or are we noobs? Noobs are the basic posts you spend your friday nights responding to so you can build up your stellar reputation lol. You're just a sad super fan, get lost.

Yeah, and luckily you were born all-knowing so let's make fun of those noobs and demean someone that actually helps them. While I'm sure that sounded like a great joke and a stupendous punchline while you were imagining it, in reality it paints your as both bitter and cynical person (as you know how Oscar Wilde put it: Cyinc is a man who knows the price of everything, and the value of nothing). And I ultimately feel kinda sorry for you. Still, if I had a choice between assisting you or 50 noobs (although that is likely in the realm of SF, seeing the opening conjecture) - guess which would I choose. And it has nothing to do with reputation - but being a decent human being willing to give something without receiving anything in return (as I could've surely used a word or two back in the day). Whereas all I see here is moaning and insisting on a niche feature with limited benefit for majority of the users and out of current scope of the project, as it has been explained in this very thread on several occassions.

@pir8radio is a well-known and respected member of the community who has helped number of users on numerous occasions, often related to quite advanced nginx configs, and seeing you dragging his name through the mud and discrediting him does provoke a degree a repulsion, as it does create the urge to type a few words. Although I've never exchanged a single sentence with the man. But his depiction of Karens fits quite well from where I'm standing (not that anyone shluld give a f*ck about that, least of all you).

Personally, I reckon it would be a handy feature that would bring certain benefits, that I might make us of. Do I think of it as absolutely necessary? Nope, by considerable lenght. Off the top of my head I could count 10 improvements that would vastly outweigh this one, for the community as a whole and not necessarily to myself personally. Seeing significant core changes this one would require, I'd rather those resources being devoted to former, until the time/need comes for latter to be developed. 

Anyway, do come down to the Earth and try to measure those expectations with some more reasonable gauges. 

My 2c.

 

 

 

Edited October 23, 2021 by GrimReaper
Typos, of course

[rsvg 14]

4 hours ago, GrimReaper said:

Yeah, and luckily you were born all-knowing so let's make fun of those noobs and demean someone that actually helps them. While I'm sure that sounded like a great joke and a stupendous punchline while you were imagining it, in reality it paints your as both bitter and cynical person (as you know how Oscar Wilde put it: Cyinc is a man who knows the price of everything, and the value of nothing). And I ultimately feel kinda sorry for you. Still, if I had a choice between assisting you or 50 noobs (although that is likely in the realm of SF, seeing the opening conjecture) - guess which would I choose. And it has nothing to do with reputation - but being a decent human being willing to give something without receiving anything in return (as I could've surely used a word or two back in the day). Whereas all I see here is moaning and insisting on a niche feature with limited benefit for majority of the users and out of current scope of the project, as it has been explained in this very thread on several occassions.

@pir8radio is a well-known and respected member of the community who has helped number of users on numerous occasions, often related to quite advanced nginx configs, and seeing you dragging his name through the mud and discrediting him does provoke a degree a repulsion, as it does create the urge to type a few words. Although I've never exchanged a single sentence with the man. But his depiction of Karens fits quite well from where I'm standing (not that anyone shluld give a f*ck about that, least of all you).

Personally, I reckon it would be a handy feature that would bring certain benefits, that I might make us of. Do I think of it as absolutely necessary? Nope, by considerable lenght. Off the top of my head I could count 10 improvements that would vastly outweigh this one, for the community as a whole and not necessarily to myself personally. Seeing significant core changes this one would require, I'd rather those resources being devoted to former, until the time/need comes for latter to be developed. 

Anyway, do come down to the Earth and try to measure those expectations with some more reasonable gauges. 

My 2c.

 

 

 

I don't read boomer books. I stopped after you started quoting Oscar Wilde lol. Take care tho old timer.

[GrimReaper 3293]

4 minutes ago, rsvg said:

I don't read boomer books. I stopped after you started quoting Oscar Wilde lol. Take care tho old timer.

Fair enough. Likewise. 

[softworkz 3335]

When you've spent half of your life on developing enterprise database applications, you can only laugh about some posters that are trying to make big speeches which are essentially only revealing that they don't have much clue about the subject - surely not the debt that db-agnostic development can put upon a project, especially when it hasn't been designed for this from the first place.

SQLite, MySQL, Oracle, Informix, MsSql, Postgres - all of them have their own range of individual differences in SQL dialect, DB organization, supported data types, trigger capabilities, indexing capabilities, statistics generation, query optimization, query-precompilation, transaction capabilities and transaction behavior - just to name a few things.

The bottom line: for a db-agnostic implementation, you either need to restrict your use of db features to a common subset or use specific coding to adapt to the differences. At the db side though, you really can't afford to have much differences. The current db structure is optimized for SQLite in a number of ways which won't work well with other dbs. This means, that the db structure needs to be reworked more than slightly. As a consequence, many of the specific optimizations that are used will get lost initially and new optimizations need to be worked out based on the new structure.

Then there's the side of the code: Due to the differences between sql dialects and supported query features, you'll need some form of abstraction layer because with the minimum common subset you won't get very far. You can either use some existing middleware for this task like nHibernate or Entity Framework (as we're on .net) or you write your own abstraction layer. The problem with the latter is that it requires a lot of work and as it will grow over time and can never be at the same level of maturity like standard middleware; it would put a significant burden on future development as it would be required to test every future change we make against every database we support.
Everybody who has worked with such middleware knows, that these often perform significantly worse than  with custom sql, when used in the default way. It requires expertise and additional effort to achieve appropriate performance which in turn frequently requires additional changes to the database structure to accommodate to the way those middlewares are working.

Finally there's another subject: DB schema updates. As the software evolves, the database needs to be changed and extended for new features, for which you need to have sql scripts,  updating the db schema. These are hardly ever compatible between different db systems (besides the most basic operations), so you will need a separate update script for each db you want to support, each time you make a change. Even though EF has some capability to create these, it is not really a straightforward process and needs to be tested against all databases you want to support.

Even if we would support MySql as a single alternative db, this would already cause significant technical debt on future development (remember, we're a very small team). 

As a matter for fact the initial outcome of doing a change like this would be:

• Bugs in all areas
  • For the majority using SQLite
  • For users trying the alternate dbs
• Decreased performance for the majority using SQLite
  We can't catch and optimize all users' scenarios during development
  => Regular users will complain
• Users trying alternate dbs will complain about performance partially being worse than with SQLite
  Let's just say: because we have focused on SQLite for optimizing and delivering the same performance as previously
  There's more to this, but that's for another day
  => Considering the mindset of some(!) users in this conversation, those complaints might be as unpleasant as their comments already made

All-in-all, one might recognize that this won't be a recipe to make anybody happy, neither on our nor on the users' side.  It will cause regressions and decreased performance and it will take a while to address all issues and catch up to the previous state in terms of quality and performance.

As painful as it would be - it's still a reasonable step to make at some point in time, but there will have to be suitable and valuable reasons to justify going through this, which should ideally bring benefits to all Emby users. A few users in the forum who are posting blown-up offensive and insulting speeches won't be such reason, that's for sure.

I have written this for all the others here, that were just kindly asking for that feature, in the hope to make the background and the decision making from our side a bit more transparent.

For those who think otherwise, here's the usual and only answer they deserve: "Yes, it's planned for the future".

[gnufreak 3]

> When you've spent half of your life

You may impress someone without any idea what you're talking about in the context of RDBMs. Agnostic frameworks accumulate technical debt? LOL, Emby's DB choice is the epitome of technical debt. When you have an attention span of a 15-year old and fail to understand simple analogies, "half of your life" isn't all that impressive. That's like a motorcyclist saying they're good, because they've been riding for 40 years. You can ride for 50 and still be mediocre, if highways are all you ever ride.

The problem is you're supporting a paid product and whine when people call out your project's shortcomings, as if you were working on an opensource project on your free time and expect people to be "grateful". You make insulting and defensive comments but get offended when people don't take crap from you. For this reason -- F your hurt feelings - it's a product that Emby is selling and which is designed as if art majors were in charge of selecting its DB engine.

As I said - I've already solved the issue for myself. I couldn't care less if you fix or break anything in emby - I'm only reading this for entertainment purposes and because I know your fragile ego will take this personally, yet again.

Edited October 24, 2021 by gnufreak

[cascan07454 0]

So any movement on this from the Emby devs? I like Emby and would honestly prefer not to have to migrate to something like Jellyfin just to get a proper database...

Edited April 7, 2022 by cascan07454

[vdatanet 1549]

4 minutes ago, cascan07454 said:

I like Emby and would honestly prefer not to have to migrate to something like Jellyfin just to get a proper database...

What database do you think Jellyfin uses?

[cascan07454 0]

1 minute ago, vdatanet said:

What database do you think Jellyfin uses?

Currently SQLite. But they openly discuss the plans to add MariaDB/MySQL and other drop in DB plugins once they upgrade their version of .NET and EF respectively. My point being they have it on the roadmap and actually seem intent on pursuing it...I'm hoping Emby is ACTUALLY planning to do the same...

[dcol 165]

My take on this is more from a maintenance perspective. The way the Emby database works is fine when it works, but when it has some issues it would be much easier fixing with a better database than having to recreate a library with 250K entries which I have had to do countless times and is very frustrating and time consuming. Emby's database gets confused too easily when changing directory locations or moving things around between libraries. My vote is for easing the maintenance rather than for speed.

[cascan07454 0]

After reading more of this thread's older posts I'm feeling quite a bit less confident that this is something Emby's Dev Team plans to roll out in anything approaching a reasonable amount of time. I'm just going to move to Jellyfin. Their Git commits leave a lot more to be excited about than what I'm seeing in Emby's beta changelog...even more so compounded by the pretty negative responses from the devs here.

Probably doesn't matter though since I paid for a lifetime rather than month-to-month, but this is another household of users lost to Emby...