Hmm … that should do it though …

Looks like manual searches are not affected, as if AutoDetect does not follow same guidelines.
However when I look at some other comments you made, I wonder if your data source is keeping up? (eg. TDVB, etc).

For one, a title “TBA” or “Episode X” is produced by a given datasource.
RMTV does not make up these names, they are provided – so either the data source provides a record (episode) which has a title (which can be “TBA”), or there is not record. 

I agree rmtvs does not make up those titles, they come from last week's query

Also note that what you see on the website of a data provider, may not be in sync with what their API is offering (I have seen this quite a few times with TVDB, so this may very well happen with others as well).

I have observed many time that api and website are not always agreeing.

But in this case, its all api that yields results, but last week's api results often differ from this morning's api results.

As far as auto detect goes, it will first try to find an episode in the database (for speed), and if it cannot find an episode, it will try to find one online.
This would explain your title issues, when an episode was previously already stored in the database with a placeholder name (TBA or Episode X).
Now, I could tell RMTV to automatically update the found TV Show, but this could come with issues when dumping multiple episodes of the same show (eg. update the same TV Show multiple times).

I could try to build that in and see how bad this will be … it’s a beta after all right? 

What are those issues you seem to expect?

As always; I tried to do this right away, but I’m afraid it may take until tomorrow for me to build something like that (long story).

The SQL error is a problem though – it will prevent the rest of the code to be executed, so part of what may need to be done will not be executed.
I’ve not been able to reproduce this, so anything that can help for me to reproduce it, is most welcome.

Apart from forwarding you a show title and episode which yielded the error, is there anything else I can do?

And I'm not even sure you would reproduce it, or maybe just the following week

Perhaps we can continue in the forum – start a topic and I’ll find you there 

Posted by: @mfu

am I to understand AutoDetect will always look up in db first, then optionnally query providers

That is correct. The idea being that a local database search will be significantly faster than an online search.
The time difference will be almost astronomical ... unfortunately.

Posted by: @mfu

Add matches to history

Add matches to hard link

I'm afraid that neither will help pulling updated info. They just add it to the hard links, which makes finding the TV Show/Episode faster for next episodes since we've now locked in the show.

Posted by: @mfu

The "counted" error

If you run into any examples that can reproduce this one, then please do send me the details 😊 

Posted by: @mfu

Looks like manual searches are not affected, as if AutoDetect does not follow same guidelines

That is partially correct. Manual searches, if the zero day option was set, will indeed update the entire show and all episodes. Auto-Detect will not.

I've been thinking about a work-around, and one would be this:

1. Do the Auto Detect
2. Based on all shows found, update all involved show with online data
3. For each episode, pull updated info.

I have to think about this a little more ... still in need of coffee in the morning to wake up 😁 

Posted by: @mfu

But in this case, its all api that yields results

Yep, the problem is clearly that data is being pulled from the local database - which explains the TBA naming and such.

One of the concerns would be if a use would want to auto detect (for example) and entire season of episodes of one TV show.
In the current mechanism, it would potentially update the TV Show over and over again.

In my head I have a potential fix ... but I'll have to do some experimenting with that to see how good or terrible it will be.

Everyone likes fast results, including me, but if autodetect searches 5 seconds longer but gives good (updated) results, its much better than quick bad results, then having to perform manual search, which ends up taking longer in the end.

I have unchecked both autodetect options (history and hard links), and haven't seen any issues for 2 morning straight.

Then again I have little shows I follow that plays friday/saturday; the next 2 or 3 days will make or break my theory.

Dont do any work on this for now, I will make sure to update you should I get (or not) more issues.

Posted by: @mfu

Everyone likes fast results, including me, but if autodetect searches 5 seconds longer but gives good (updated) results, its much better than quick bad results, then having to perform manual search, which ends up taking longer in the end.

I'll try to think of an option the user can enable to update a show if one is found.
As for speed, you's potentially be looking at a delay of maybe 5 seconds per detected episode - depending on the used data provider and your Internet connection.

But ... I do have an idea that may makes this around 5 seconds per TV Show (versus per Episode).
I could use the tag that I use for when the show was last updated. So when a show was detected and the tag isn't indicating say an hour ago, then update the show info.

However, hearing you talking about recent episodes, I'd guess you're only having one episode per TV Show when doing an auto detect.

On that note, maybe a button "update all TV Shows" may be a good alternative - again not sure how bad performance would be though. 

I'll have to think about this for a little bit - let me know what your thoughts are.

p.s. just uploaded beta 2.1.6 ...

This does not resolve the issue we're discussing here, but it does fix 2 small bugs and a memory leak I ran into ... 😊 

@hans 

thanks

Hi,

after a week with hard links options turned off, I have not experienced Counted error crash, nor placeholder titles.

To be more exact, I encountered 2 tba instances, but for those, even a brand new search gave same results.

Obviously, not much can be done in those very specific and rare cases.

What I wish to avoid is looking for a show and getting an "obsolete" saved title, when a new search produces updated correct title.

While the goal of hard links and history make sense in theory (speedup the process), my usage reality is last week's title will often (33%) be missing/tba/placeholder. Again, the only thing missing in RMTVS settings is in TV Show History; an option to prevent history buildup.

Thanks

Posted by: @mfu

after a week with hard links options turned off, I have not experienced Counted error crash, nor placeholder titles

Awesome - that is useful info!

As for the hard links - I'm surprised to see this "side effect". Not what I would have expected.
I'm trying to find some time to get into the details for this, since the main purpose of hard links is speed in detection of the correct show. 🤔 

Posted by: @hans

Awesome - that is useful info!

As for the hard links - I'm surprised to see this "side effect". Not what I would have expected.
I'm trying to find some time to get into the details for this, since the main purpose of hard links is speed in detection of the correct show. 🤔 

 

The root cause being providers accounting for (or not) a latest episode, or they going temporary to actual episode title at the very last possible moment, as in air date. Should they create a whole season's of complete and accurate data all at once, as a new season begins, History and Hard links would then work perfectly.

By the way,I barely notice a speed difference with hard links turned off, having a highly capable pc / internet plan might help

.

Posted by: @mfu

I barely notice a speed difference with hard links turned off

I think this becomes more relevant when show titles are awkward - if you know what I mean 😁 
Also when a computer is less powerful of course.

Oh well, I will try to make some time this week. With family and work issues, I'll have to try to squeeze it in somewhere. 😉