tvrenamer
tvrenamer copied to clipboard
tvrenamer
choosing numbering scheme
For each episode, our current provider may provide numerous options for "season number" and "episode number". Three known options are:
- "Regular", which means, according to how the episodes were originally aired
- "DVD", which reflects how production companies often re-order the episodes for DVD release
- "Absolute", which is more useful for shows that don't really air in discrete seasons
For any given show, it may make sense to use any of the three orderings (or a fourth?). But it doesn't make any sense to ever mix-and-match for a given show.
We can do three things, not necessarily mutually exclusive:
- Allow users to express a preference for one naming scheme (via the preferences dialog)
- Allow users to express a preference on a per-show basis (but UI???) 3, Once we have downloaded all the episode information for a show, choose the numbering scheme that makes the most sense for that show
Thoughts?
Option 3 would be the best, then the user has a result to work with. It's it's incorrect, then they change change some sort of setting and see the change be reflected in the 'Proposed' column to confirm that it's correct. However, they need to know that the order could be wrong. How would they know that the "Regular" and "DVD" order is different for say Firefly?
How much work (coding/networking) would it be to download and parse all the orders and if they are different (or maybe the "Regular" and "DVD" orders are different) then display that to the user?
Also not sure how we would do the UI for a specific show- it's all file/episode centric at the moment. I'm not sure if something similar to an <select><optgroup> (see HTML reference) exists for SWT? Then we could have some sort of clickable element on the 'Show' group...
https://github.com/tvrenamer/tvrenamer/blob/master/src/main/org/tvrenamer/model/Show.java#L191-L220
We do download and parse the various episode numberings. Right now, we count how many episodes have DVD information, and how many don't, and if the vast majority have DVD information, that is used. That is, if no numbering scheme is explicitly specified. The functionality is there to have an explicit specification, and in fact there are tests that use it, but I haven't exposed it through the UI at all yet.
Suggestion: How about adding an additional column in the UI where it says numbering scheme, with values AirDate/DVD/Absolute, and allow the user to change that value using a dropdown menu. The value of that column should be linked to the TVDB show id, so the next time you load the UI it will populate with the value that was selected earlier. If you change the value in one row then all other rows that have the same show id should probably also be changed. When you change the value the proposed filename should be recalculated.
@robinsmidsrod That's a good idea, although that might make it seem like a per-episode setting, which it isn't (and I don't think it should be). Is it something you would be able to help implement?
@eprenamer I agree it might make it look like a per-episode setting, but I think if you visually change the other rows when you change one then people will understand that it is a per-show setting fairly quickly.
My Java skills are quite rusty, but I can help with architecture and interaction logic if you need some assistance.
Do you already have a system in place to save settings/configuration in either the registry or a config file? If not, I might be able to assist you with some cross-platform code (from an older personal project of mine) to find the user home directory.
A simple CSV/text file with two columns, one with show_id and the other with episode ordering preference should probably do it. You can load it in on startup and write it back out on exit. If you already have a better way to serialize a key/value mappings then use that instead.
We do have a preferences file now. There's a UserPreferences object, and we use a library that translates from an object to XML and back again.
I have worked on other ideas of having the user's "favorite" or "known" shows stored to disk, and the setting (which type of numbering scheme) would naturally fit in there. But that hasn't been integrated into master yet.
Basically we were using XML for everything, in part because that's what we were getting from the provider (thetvdb). But we are in the process of switching to TheTVDB v2 API, which uses JSON, and it might make sense to switch to JSON for everything.
Just a bit of context, the choice to use XML was (not really) related to the upstream provider using XML, it was more about the ease of use (at the time) of the xstream library.
We could consider switching to another file format for the preferences if there was a good reason for it. At the moment I don't think using XML/xstream is too big a deal - the preferences file isn't unwieldy (yet!).
If we did switch to something else we'd of course have to have a one-time migration step (like @eprenamer has done already), but we'd have to have the XML preference reading logic (and library) in the app for some period of time after we make the switch.
We could also just leave the preferences file as XML, and use a different file format for other data persistence. Using JSON is probably the best option since we're introducing a JSON library as part of the switch to TheTVDB's JSON API.
@eprenamer I would just use whatever format that works without giving you too much extra development work. No need to change the storage format of the preferences unless there is a compelling reason. Obviously getting the size of the binary down by being able to chop out the XML parser/serializer would be useful, but only if it has a significant impact on either download size or startup time.
If you plan on serializing data directly from TVDBv2 then having persisted data be in JSON is probably a good thing to avoid having to convert it using a custom conversion logic (between JSON and XML).
So yeah, it seems like my vote goes for preferences in XML (as it currently is) and data persistence in JSON (for future compatibility with TVDBv2 JSON API).
I suppose I'm making an assumption that serializing a POJO to JSON is relatively trivial -- at least, once the project is already using three JSON-oriented library, which is now the case. If it's not trivial, if it takes some real work, then sure, it makes sense to keep using XML.
I opened yet another issue ( #256 ) but now I'm thinking I should have just updated this one. Here's what I wrote, there:
When considering season and episode number, we prefer the DVD numbering, but fall back on the production ordering. We knew this could cause conflicts, and I've found an actual example, now, for the show Robot Chicken:
This one has production ordering S08E13, but DVD ordering S08E14: http://thetvdb.com/?tab=episode&seriesid=75734&seasonid=642097&id=5550267&lid=7
Since we prefer the DVD ordering, we consider "Joel Hurwitz Returns" to be S08E14.
Then we have this episode. It has production ordering S08E14, and no DVD information. I suppose that means it wasn't included in the DVD release? http://thetvdb.com/?tab=episode&seriesid=75734&seasonid=642097&id=5578960&lid=7
So, in our current implementation, we try to map both of these to S08E14. So if you load up the show and ask for episode S08E14, it's basically undefined which one it will give you.
@eprenamer Well, if you can choose which ordering you want for each TV show then I think it will be a non-issue. But trying to auto-detect which ordering to use for each TV show is a recipe for confusion, as you mentioned. I would instead recommend that you have a setting for the default ordering to use and then an ordering for each TV show (which could be set to default) as mentioned in my previous comment.
@robinsmidsrod I think what you said, by itself, doesn't solve the problem. Even if we make it exposable on a per-show basis: what if someone chooses "DVD" as their preference for Robot Chicken?
I assume that if they've made it explicit they want DVD ordering, then "Joel Hurwitz Returns" should be S08E14 for them.
But then, what do we do with "Hopefully Salt"? Just omit it from the index altogether?
Note that if you ask TheTVDB to show you season 8 of Robot Chicken using "DVD Order", it includes episodes like "Hopefully Salt", but with no episode information:
http://thetvdb.com/index.php?lid=7&seasonid=642097&seriesid=75734&tab=season&order=dvd
If we do omit it, are we omitting it only because it has a conflict? Or, if the user chooses "DVD", does that mean we omit ALL episodes which lack DVD information?
I can see an argument that it's reasonable to omit it, but I still think it's a bad experience.
For me, as a user, I'd like total control over the numbering. I'd like to be able to specify a default numbering, but be able to change it arbitrarily. But not only is that a lot of work, it's also probably confusing and overwhelming for most users.
So, I still don't see a clean solution. I assume others believe I'm overthinking this, but I'd like to get it right. :-) I'm interested to hear how others would handle episodes that have no DVD information, when the user chooses DVD ordering.
@eprenamer To be honest, if DVD information is missing on an episode and people try to rename it to that, you should probably find a way to inform the user that the information is missing and they should sign up for a TVDB account to fix it (if that is possible). Alternatively you can give them a UI for manually setting the season/episode number. For the file in question you should probably skip processing it, so that whatever metadata they already have in the filename is not lost (because it is most probably correct).
@robinsmidsrod Hmm, that's not really what we do, though, right? It's more, they have a file on disk that they've labeled "Robot.Chicken.S08E14.avi", and they've asked us to rename it to add the episode title. Which title do we add? If they've specified "DVD", then that answer becomes easier. But what if they then have "Robot.Chicken.S08E15.avi"? Do we just say no such episode exists? Such an episode does exist, in the non-DVD ordering.
But we can also think of what would be the right thing to do if presented with a file called "Robot Chicken - Hopefully Salt.avi". Now, true, right now, we don't do anything like that. We would say "no episode information found", because we currently need a season and an episode to even get started. However, it would be nice to be able to support that (renaming based on titles) in the future.
There are lots of other features we could do, like "tell me which episodes of this show I'm missing". And I want to try to think about numbering in a way that helps support any of that.
But first priority, I suppose, would be to do what the program already does. So again, what do we do if they have S08E15 of Robot Chicken, and they've chosen DVD ordering?
@eprenamer I think consistent ordering trumps availability. If an episode does not have order information for the order type you want then the application should not do anything to the filename. It's just like NULLs in databases, they represent the absence of a known value. Although I think it could be wise to inform the user that information DOES exist for another order type, because that might inform them that they are using the overall wrong order type for that series. Getting some of my episodes ordered by one order type and some from another is, to me, a recipe for confusion.
I would love to go the other way, though, from title to episode number, and again, consistency with order type would still be the most important thing.
To be able to do these things in a flexible way it seems like the only option you have is to figure out some way to allow for multiple variants to rename a filename, possibly with a dropdown-box for each line, with an indicator that there are alternatives. Maybe that would work? I also think a column with additional information would be useful.
I totally agree about the recipe for confusion; that's the basis of this Issue report. :-)
And yet, the reality is that it may happen that people have some files numbered according to the DVD scheme, and some (of the same show) numbered according to the production ordering.
Currently, screen real estate is at a premium. There are lots of columns I'd like to add, but there's not much space. Maybe if we could let configure which columns they want to see, then we can add some.
But another thing I want to do is be able to generate a dialog box for each line, which can be much more detailed.
I think for the immediate issue, you're right that by default we shouldn't mix-and-match. I think what can help is more specific messaging, e.g., "No such episode: DVD ordering, season 8, episode 15, Robot Chicken". (I'm referring here to the "Proposed File Path" column, which we use for error messaging.)
Alas, I still don't think we have a UI solution for how the user can specify which ordering they prefer. Sorry but I really don't like the idea of having a check-box on each line, if we actually are doing it on a per-show basis.
I think in the short term, all we can do is offer it on an application-wide basis (applying to all shows) and make the messaging more specific.
@eprenamer I was actually thinking of a drop-down menu instead of checkboxes, and if you use icons instead of text you it wouldn't take much real-estate, but I agree that configurable columns is probably the way to go. I would probably enable a column for show name, as it is sometimes confused when you try to add "The Office". Is it the UK or US one?
But as a first, if you add the message with "no such episode found..." and possibly a drop-down box at the top for which ordering type is currently used then I think it would be easy for the user to change the ordering when they are renaming episodes for a specific show. If that would be saved on exit then at least people have a way to indicate their preference, and we can get to per-show preferences at a later time.
When it comes to choosing order for specific TV show, you could have another preference window (or tab in the existing one) where the ordering of each TV show that has been fetched with the application so far are listed. That way users could change their preference there, and when those preferences are modified you would recalculate the rows in in the main window related to those shows if the preference was changed, or just always recalculate when you close that window.
Thanks @robinsmidsrod
@vipuldelwadia @daveharris Do you have any input? I think you probably would care a lot more about user-visible changes, and I only want to implement things that you approve of.
@trolley Did you get anywhere on this? I am back to working on it myself, and I don't want to conflict.
No, go ahead. Between family stuff and work I’ve been swamped and hadn’t got to it yet.
On Oct 9, 2017, at 6:16 PM, eprenamer [email protected] wrote:
@trolley Did you get anywhere on this? I am back to working on it myself, and I don't want to conflict.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
