[Discussion]: Subdirectories for chromaprints about intro-skipper HOT 5 CLOSED

So there's no issue and you're not sure how there would be an issue, but propose we radically change the entire core of how the scan process is designed because you suspect there may eventually be the possibility of an unknown bug?

Think maybe you are just searching for something to report?

from intro-skipper.

Well, besides broken shell expansion and possible performance degredation (this may be dependent on filesystem type), this should not affect the functionality of the program in any way. To answer your two questions though: No. This is not a feature request or a bug that I am reporting. Also, my proposal was that "this change should eventually be considered" (I still think this). Not that this change be worked on or implemented immediately. It is just something that I thought should be discussed and/or considered by people who know more about programming than I do. That is why I put "[Discussion]" in the subject header.

Surely there is a reason why all other programs that create a large number of files use a subdirectory structure? File iteration times? Inodes? Again, I am not a programmer and this is not my field of expertise. I started this post hoping that an intelligent conversation could be had about the structure being used between the programmers working on this project, not necessarily with me. I can assure you that it was not meant to be an topic that affected the emotional state of the reader. Maybe I'm wrong and none of this matters in the context of performance or other filesystem related issues. I don't actually know (that's part of why I made this post). It is just something I noticed that was different about how this program functions as opposed to other programs that also create very large numbers of files, so I wanted to bring it up in case it matters. I hope that clears up my original intentions. If, for some reason, you do not think this is even worth discussing I can simply close this thread so that it does not appear in the open issues section if you would like.

from intro-skipper.

Since you asked, the reason all files are kept in the same folder is how they are made and what they contain. They are made using ffmpeg with a very minimal set of arguments and contain a list of numbers. If we were to iterate through the directory, it would be a lot. If we were to attempt to find an unknown file among them, it would be a lot. We write to the files and then use them by name.

Ideally, everything would be written to a database contained in a single file. That's why the part where we do search and do iterate is an xml. The cache files are meant to save time on scans. It sounds like this all traces back to tampering with them.

But say we decide to invest the time dividing the files up, tracking where they're placed, and all that stuff. How to we determine the folder? Season? What if you placed an episode in the wrong one? Sure, we can use the scraper season assignment, but what about when you change scrapers? That's probably not going to work. Alright, so we do alphabetical. A folder for every prefix. We get the episode id, get the prefix, check for a folder, create the folder, then we can write the file like before. When it's time to use it, we have to determine the episode id again, get the prefix again, check for that folder again, open that folder again, then we can finally do what we were doing before to read the file. Seems like a lot of extra steps to facilitate manually tampering with cache files.

from intro-skipper.

Oh, I see. So, instead of an improvement in performance, we would see a decrease in performance due to all the extra steps required for the checks? Well, nobody wants a slower scan (I certainly don't). I thought about the database idea too, but that seems like it may not be possible or be extremely difficult to do in a plugin (assuming more depencies on the host would be required for it to function at all?). Okay, well if it doesn't make sense (which it doesn't seem to at this stage) then I should probably close this conversation for now. I wasn't trying to be critical before, just helpful. I hope that what I wrote was not perceived in that way. I am actually quite appreciative of your help and the other devs help on this project. Thanks for the explanation/your patience.

from intro-skipper.

No worries. It's less about feelings than trying to find if there was a more rational reason that could cancel out the one against it. It's also not uncommon that some issues are literally to create work. It's never done with bad intentions.

from intro-skipper.