HT5 v4.3.70 ALPHA Test Version

So, on my largest directory, I've been running into issues, and HT5 has crashed a few times.

I've since cleared all cache, restarted the unit, and am rescanning. The problem with HT5 however, is that it doesn't provide the end user with any meaningful data. I don't know why it's freezing, where it's freezing, etc. I have no idea if there's some odd show that it's hung up on, or what. But as I mentioned in my prior post, other directories that it would freeze on, it's not completing at 100%. So it's not a naming issue as far as I can tell. I haven't renamed anything since loading this Alpha build.

Furthermore, at this point, the scanner seems to get stuck (when it doesn't just crash). It's fully scanned the total number of files in the directory, but is stuck on the number of those it had matched. The progress bar has stopped moving, and the matched number is no longer climbing. At this point, I have no idea if it's actually working in the background (and the progress bar is just stuck), or if the full thing is stuck.

Also, once HT5 crashes, the directory it was scanning when it crashed will just perpetually say it's "Scanning", but then I can see other directories start scanning and actually show the progress bar moving.

So, for now, unless I can troubleshoot this and get it to work, I'm back to HT5 being unusable unfortunately...

 

I have tried both options, no luck.

 

Just a real example in HT5-Posterwall and Spanish language:
1) Automatic scan from source (NAS).
2) Unmatched movies... found "Float (2024)".
3) Match manually, searching "Float (2024)".... nothing.
4) Search just "Float" and find a long list including "Float" 2024.
5) Then Select and Accept to match the same file you got from the beginning and first of the list.
Suggestion: Choose the newest movie from the list, easier way than to leave it unmatched.

 

I'm still a little confused over what you named your file - if you named it "Float (2025)" then that's incorrect - there isn't a movie called "Float" from 2025 listed in TMDB.


To replicate, I changed both the UI language and HT language to Spanish and added a dummy movie simply named "float.mkv" and HT found it automatically first time.

There are 15 movies on TMDB called "Float" from between 1987 and 2024 so HT picked the latest one as below:



I also tried naming the file "Float (2024).mkv" and HT scraped that correctly too.


I then changed the movie name to "Float (2025).mkv" which is incorrect, and of course there isn't a movie named Float from 2025 in TMDB, so it picked "Floated By" which is a 2025 movie so I guess it picked the nearest it could find in 2025 as below:



If you actually go to the TMDB site and query "Float" in 2025 by entering <Float y:2025> then it returns zero results, so at least HT is applying some logic to the incorrect query.

So, as far as I can see, the logic is sound.

 

Sorry but I wrote 2025 wrongly. It should be 2024 as first line. And in my case never select "Float 2024" automatically. I'm not running alpha 4.3.70 but previous one.

 

Not sure exactly what's going on but I assume that in updating the database for the new schema in this release, the "Date Added" field has been updated. This is a field in the database that contains the epoc date for when the file was added to that database using the onboard clock.

If you have sort order set to "Date Added" is there any logic you can see to the order? alphabetical maybe?

I always use Modified Date because that uses a field in the actual file of when it was modified which will usually be the same as the creation date (which would be the ideal) unless of curse the file's been buggered about with.

The reason I do that is that I continually reset, rescrape and generally abuse my database so "Date Added" (or ADDED_TIME in the database) is meaningless.

If I get instances where Modified Date is different to Creation Date in the file, I use some nifty utilities from Nirsoft to make changing them easier either individuallY:

FileDate Changer v1.1 - Change the created/modified time of files

Or in bulk:

BulkFileChanger: Change date/time/attributes of multiple files

 

Ah - this is the v4.3.70 thread

 

I can't find a Float (2025) entry on TMDB. There is a Float (2024). Tested with TMDB set to es-ES and en-AU.

If I name a file "Movies/Float (2024)/Float (2024) 1080p.mkv" it's matched automatically when I do a scan. My Zidoo is set to English. If your file is named correctly (like I show in the example above) and it doesn't match with Zidoo set to Spanish, then that may be a source of problems. You should be able to confirm by switching to English and trying a re-scan.

 

any change can we set online trailers for hd quality?

 

No, there is no reliable scrapable online resource on which to draw - if you want HD or UHD trailers you have to use local trailers.

 

Already sorted:

https://forum.zidoo.tv/index.php?threads/ht5-v4-3-70-alpha-test-version.100779/page-3#post-257635

https://forum.zidoo.tv/index.php?threads/ht5-v4-3-70-alpha-test-version.100779/page-3#post-257641

 

I'll update to this alpha version and come back with output. But the issue is really old!!

 

It took several hours for my post to appear. Probably forum issues.

 

Fw 1.2.25 -HT5 4.3.70 exactly same behavior with another movie:
1) Automatic scan from source (NAS).
2) Unmatched movies... found "Aun estoy aqui (2024)".mkv
3) Match manually, searching "Aun estoy aqui (2024)".... nothing.
4) Search just "Aun estoy aqui" and find just one in the list "Aun estoy aqui" 2024.
This issue is happening like 3/10 of new entries.

 

Again, incorrect naming.

It's not "Aun estoy aqui", it's "Aún estoy aquí" with accents above the ú and í - essentially different letters with different ascii values.

For parsing text it's a bit like saying "big" is the same as "bag" in English unless logic is applied for accented letters.

If you use the correct spelling "Aún estoy aquí (2024).mkv" it works first time.

 

I'm very sorry but it doesn't need any accented letter as shown hereby although it needs to remove the (year) instead. It means that manual matching is less demanding and doesn't need accents to go through... maybe!!

 

I understand what you mean because the manual search will find it whereas an automatic scrape does not, but this has always been an issue.

The bottom line, if you name the files correctly, it works, and I know in your case the difference is small, but it still doesn't detract from the fact that your file was named incorrectly.

What makes it more complicated is that there are several dialects of Spanish available on TMDB and the movie title varies per dialect - on some the movie is listed by its English name and Portuguese name together and on some in traditional Spanish - you can't possibly expect a scraper to cope with all that!

 

Actually it has nothing to do with dialects nor TMDB but with accents. In fact I never use accent in my title naming while English doesn't use it. My suggestion for improvement is simply don't take in consideration the accents as the word won't change at all.

 

I am happy the flashing posters are gone/ are fixed.

 

That's actually a non-trivial problem. Unicode is complicated. Text transformations are best done right at the user input level (ideally with the ability for the user to correct the transliterations) or at the backend database level (TMDB), which has intimate knowledge of the data being stored. The best course of action would be to ask TMDB to enhance their search functionality to implement these enhancements. Implementing this differently in each client that connects to the database seems silly.