Library for YouTube channels

[Luke 42077]

What problem exactly did you have when using the home videos content type?

[nino12 2]

4 minutes ago, Luke said:

What problem exactly did you have when using the home videos content type?

I already wrote that a few posts ago: "I tried Home video and Photo before, but my experience is there's almost no structuring possible and therefore it's almost impossible to find stuff once the library is getting larger, so it doesn't suit my needs. There's also no documentation for this library type, so it's completely unclear to me how things work."

To be a little less vague: Once I have two or more channels in the library, it is not possible anymore to see from which channel a video came from. There's no filter for that. And searching for the channel name doesn't work as well. Sorting by different values (f.e. by date) also doesn't work. It seems it's just a bunch of videos without any functionality other than playing them.

Nevermind, please don't waste your time on that. I've already decided to just get rid of Emby and replace it with another software. Maybe I'll even start writing my own, we'll see ...

[softworkz 5066]

57 minutes ago, nino12 said:

3 hours ago, softworkz said:

It would be possible to work around this by creating a custom metadata provider which fixes season and episode numbers.

There's a saying in Germany: "If that's the solution, I want my problem back"

I'm certainly not going to write my own metadata provider because nobody cares that the parser is buggy. I'd rather get rid of Emby and find a proper software to replace it.

I understand that, i just wanted to mention a possible way.

5 minutes ago, nino12 said:

Maybe I'll even start writing my own, we'll see ...

Well - then, my suggestion would be a lot easier to implement  

[softworkz 5066]

1 hour ago, nino12 said:

I'm certainly not going to write my own metadata provider because nobody cares that the parser is buggy

Before calling the parsing "buggy", you need to see this in relation: It's been quite some time ago that I've seen anybody having issues with the parsing of file names of TV/series episodes. It's doing it's thing in a way that is working for 99.99??? % of cases that Emby users are encountering. 
The most recent case I've seen was actually my own case when working on a new plugin which involves parsing episode and season number out of titles from certain sources. 
Now I knew that all this regex logic is very sensitive as it has grown and maturized over time. A minimal change you would do to support an additional case has high potential to cause regressions for other cases. Also, you cannot simply allow setting custom regex expressions because:

• It's a multi-step procedure
  multiple regex matches are attempted in a certain order
• Each regex expression against which a match is attempted needs to be accompanied by program code which is aware of the potential match results and their meanings

It's not something that can easily be made configurable like you've been alluding to.

I ended up doing my own parsing and setting the results through a custom metadata provider - that's why I know that it's a workable way.

It would be possible to make the whole procedure more configurable, that's for sure, but you also need to see that you're the first one since a long time to call the name parsing as "buggy". I have a lot of sympathy for your use case, and I can only acknowledge that the current parsing doesn't fit well for that case.

[skidmarks 199]

I dont understand the problem exactly, but i can't even begin to tell you how many specialized folders i have. From sports to military to knitting to educational and so on.  I use mixed content folders and use a TV Show structure for naming.  Turning off all meta fetchers in these folders.  Works perfectly!  Some of these folders have 100's of files in them.

It just isn't automatic and you need to set up the folder structure like TV shows.  It will do exactly what you are trying to accomplish.  But you will need to label items and number them accordingly.   

[nino12 2]

 

9 hours ago, skidmarks said:

I dont understand the problem exactly, but i can't even begin to tell you how many specialized folders i have. From sports to military to knitting to educational and so on.  I use mixed content folders and use a TV Show structure for naming.  Turning off all meta fetchers in these folders.  Works perfectly!  Some of these folders have 100's of files in them.

It just isn't automatic and you need to set up the folder structure like TV shows.  It will do exactly what you are trying to accomplish.  But you will need to label items and number them accordingly.   

Let me try to explain the problem:

First, let's have a look at the following filename: "Game Two (2005) - 2018-06-02 - Agony, Moonlighter, Yoku's Island Express, Bloodstained, Far Lone Sails Game Two 72.mkv". BTW, I'm preferring embedded titles over filename in library settings. That is working exactly as intended and expected: 

Next one: "Game Two (2005) - 2018-06-17 - E3-Roundup 2018 XXL So viele geile Spiele gab's noch nie Game Two 74.mkv"
Here the parser starts messing things up, taking the "E3" from the title as episode number and ignoring completely that he has a date to work with:

Question: Where does the "S17" even come from?

Next approach I tried was replacing the titles with video ids, like so: "Game Two (2005) - 2018-06-02 - yTQTFaPE7EGMo.mkv", "Game Two (2005) - 2018-06-17 - njzRcDxMCgEE5.mkv", "Game Two (2005) - 2018-07-21 - E31moRg7rD_EM.mkv". Please note there is an "E" followed by one or more digits in every ID. Here are the results:

"Game Two (2005) - 2018-06-02 - yTQTFaPE7EGMo.mkv": 

"Game Two (2005) - 2018-06-17 - njzRcDxMCgEE5.mkv":

"Game Two (2005) - 2018-07-21 - E31moRg7rD_EM.mkv":
Ouch. Here's the problem again. Where does the "S21" even come from?

 

10 hours ago, softworkz said:

Before calling the parsing "buggy", you need to see this in relation: It's been quite some time ago that I've seen anybody having issues with the parsing of file names of TV/series episodes. It's doing it's thing in a way that is working for 99.99??? % of cases that Emby users are encountering. 
The most recent case I've seen was actually my own case when working on a new plugin which involves parsing episode and season number out of titles from certain sources. 
Now I knew that all this regex logic is very sensitive as it has grown and maturized over time. A minimal change you would do to support an additional case has high potential to cause regressions for other cases. Also, you cannot simply allow setting custom regex expressions because:

• It's a multi-step procedure
  multiple regex matches are attempted in a certain order
• Each regex expression against which a match is attempted needs to be accompanied by program code which is aware of the potential match results and their meanings

It's not something that can easily be made configurable like you've been alluding to.

I ended up doing my own parsing and setting the results through a custom metadata provider - that's why I know that it's a workable way.

It would be possible to make the whole procedure more configurable, that's for sure, but you also need to see that you're the first one since a long time to call the name parsing as "buggy". I have a lot of sympathy for your use case, and I can only acknowledge that the current parsing doesn't fit well for that case.

Do I understand the statement correctly? Because a software works as intended in most cases, it has no bugs? Congratulations, Windows, Linux and macOS, you are completely bug-free!

Now, seriously: How are people who don't use a feature supposed to have problems with it and report them? A bug is a bug, no matter how often it occurs or whether it even occurs at all. This does not change even if the developers decide to ignore it.

I totally understand that you don't want to and can't take care of a special case if there are also problems that occur with many more users. But you should at least accept that it's a bug and adapt your documentation accordingly, because it clearly states that I can do it the way I tried. In addition, the parser itself proves that it is basically capable of doing this.
Otherwise, a paying customer will not feel that he has been taken seriously and will be more likely to refrain from buying something from you again and recommending your products.

[GrimReaper 4739]

23 minutes ago, nino12 said:

Ouch. Here's the problem again. Where does the "S21" even come from?

It comes from "21 - E31" part of your filename (...2018-07-21 - E31moRg7rD...) and results in S21:E31, same as 

23 minutes ago, nino12 said:

Question: Where does the "S17" even come from?

comes from "17 - E3" part in that file (...2018-06-17 - E3-Roundup...) and results in S17:E3.

What I don't understand is why do you have to have any episode title or extradata in your filename, all your episodes are already distinguished by airdate and you're using embedded titles that you'd see in the UI (even if you weren't, they'd still be distinct episodes based on airdate) - so if insisting on using TV shows type library, why don't you just dump all extradata except "ShowTitle - Airdate" and spare yourself some pain? 

Edited September 6, 2024 by GrimReaper

[nino12 2]

8 minutes ago, GrimReaper said:

It comes from "21 - E31" part of your filename (...2018-07-21 - E31moRg7rD...) and results in S21:E31, same as 

comes from "17 - E3" part in that file (...2018-06-17 - E3-Roundup...) and results in S17:E3.

What I don't understand is why do you have to have any episode title or extradata in your filename, all your episodes are already distinguished by airdate and you're using embedded titles that you'd see in the UI (even if you weren't, they'd still be distinct episodes based on airdate) - so if insisting on using TV shows type library, why don't you just dump all extradata except "ShowTitle - Airdate" and spare yourself some pain? 

Oh yes, of course. I completely overlooked the most obvious.

Because there may be more than one video per day in one channel, so the filenames have to contain a unique component. To compute season and episode numbers is not possible, because as you can see in the screenshots if an episode has season and episode numbers the date is reduced to the year, but I need the full date everywhere the episode is shown.

[GrimReaper 4739]

8 minutes ago, nino12 said:

there may be more than one video per day in one channel, so the filenames have to contain a unique component.

You could try inserting a keyword in your regex after airdate ("title", "episode" or whatever suits you) or simply add alphabetic identifier (A, B, C...) on same-day releases so you break "day - title starting with Ex" or "day - id starting with Ex" pattern/occurrences that result in erroneous parsing. 

Edited September 6, 2024 by GrimReaper

[nino12 2]

12 minutes ago, GrimReaper said:

You could try inserting a keyword in your regex after airdate ("title", "episode" or whatever suits you) or simply add alphabetic identifier (A, B, C...) on same-day releases so you break "day - title starting with Ex" or "day - id starting with Ex" pattern/occurrences that result in erroneous parsing. 

Adding some characters to the start of the ID without whitespace to fool the parser?

Now that's an idea!

I will give it a try and get back to you.

[GrimReaper 4739]

Theres several variations you can try:

1) 

Game Two (2005) - 2018-06-17 - TtlE3-Roundup 2018 XXL So viele geile Spiele gab's noch nie Game Two 74.mkv

2) 

Game Two (2005) - 2018-06-10.mkv

Game Two (2005) - 2018-06-17 A.mkv

Game Two (2005) - 2018-06-17 B.mkv

Game Two (2005) - 2018-06-17 C.mkv

Game Two (2005) - 2018-06-24.mkv

3)

Game Two (2005) - 2018-06-10 A.mkv

Game Two (2005) - 2018-06-17 A.mkv

Game Two (2005) - 2018-06-17 B.mkv

Game Two (2005) - 2018-06-17 C.mkv

Game Two (2005) - 2018-06-24 A.mkv

4)

Game Two (2005) - 2018-07-21 - IDE31moRg7rD_EM.mkv

or whatever string you fancy. 

Edited September 6, 2024 by GrimReaper

[nino12 2]

I'll try it with video ids beginning with "YT" first. For automation, this is the simplest option. I have a feeling, if there is some kind of numbering in the titles (f.e. "#1", "#2", "#3") the parser will see this as an invitation to produce nonsense again.

[pwhodges 2012]

4 hours ago, nino12 said:

I have a feeling, if there is some kind of numbering in the titles (f.e. "#1", "#2", "#3") the parser will see this as an invitation to produce nonsense again.

The trick is to provide it with input that generates nonsense which works for you!

Paul

[nino12 2]

5 minutes ago, pwhodges said:

The trick is to provide it with input that generates nonsense which works for you!

Paul

Yes, that's what I'm saying. Since the parser unfortunately produces nonsense from data that makes sense, you have to feed it with nonsense so that it hopefully produces data that makes sense. I'm not sure whether such a software will be successful in the long term.

[pwhodges 2012]

The difference between your viewpoint and mine is that I don't view all software that doesn't work the way I want as "buggy"; also, adapting your input to suit is not necessarily "nonsense"..

Paul

[nino12 2]

20 minutes ago, pwhodges said:

The difference between your viewpoint and mine is that I don't view all software that doesn't work the way I want as "buggy"; also, adapting your input to suit is not necessarily "nonsense"..

Paul

This is a case that is described in the documentation, which makes it an official feature. A feature that does not work reliably even though the input data is clean. This is the definition of a bug.

[nino12 2]

And here we go again: "Game Two (2005) - 2022-02-12 - YT-e8PLCtA8bI.mkv"

I'm done with this software. I give up.

Thank you all for your time and help!

[GrimReaper 4739]

1 minute ago, nino12 said:

"Game Two (2005) - 2022-02-12 - YT-e8PLCtA8bI.mkv"

You have an extra dash there, after YT, so this suggestion not quite tested 

6 hours ago, GrimReaper said:

Game Two (2005) - 2018-07-21 - IDE31moRg7rD_EM.mkv

or whatever string you fancy. 

 

[Happy2Play 9780]

As the documentation for TV is only valid for online cross referencing and I guess need a little more verbage to the fact as an air date alone will not provide required Season/Episode numbers to appear in a tv library.

But to by fair the KB only say airdate and nothing about the addition of episode title.

By date
Common for long-running daily shows, you can also use the date the episode aired.

anything_1996.11.14.ext
anything_1996-11-14.ext
anything_14.11.1996.ext

So anything after the airdate can be problematic as this is technically not a Series/Show that exist on any provider to get required info.

[Luke 42077]

On 9/6/2024 at 5:14 PM, nino12 said:

And here we go again: "Game Two (2005) - 2022-02-12 - YT-e8PLCtA8bI.mkv"

I'm done with this software. I give up.

Thank you all for your time and help!

Hi, yes this is a false positive that we'll need to take a look at. Thanks.

[Happy2Play 9780]

3 minutes ago, Luke said:

Hi, yes this is a false positive that we'll need to take a look at. Thanks.

Yes in the end these are airdates with no season/episode numbers.