HT5 v5.0.68 Beta Version for Realtek 1619BPD (UPDATED)

this is for the first start, it looks like an import for the old settings
but please watch one episode and see if something was changed

 

I tested but nothing has changed.

 

@Markswift2003 I finally figured out what was causing the issue!

After updating to v5.0.68, everything disappeared again in HT5. Turns out the culprit was the "ignored words" setting. I had it set to The, Le, Les, La, L', and simply removing L'—so it reads The, Le, Les, La—fixed everything.

Funny enough, v4.3.52 handles L' just fine, but v5.0.xx doesn't.

If anyone else runs into this, the fix is super simple!

 

Awesome!

Well spotted!!

 

Sometimes the episode number is correct. But not always, probably also because of the bug of the duration of the episodes all the same.

 

Bug continuous scanning fixes with local saving of posters. But you have to wait a day or two before it works. I don't know why, but even with full shutdown it didn't work. Only after two days did it work without doing anything.

 

I just installed your latest beta. I found it to be loads faster scraping and updating via selection, before it ran like a dead horse.
I used your manager to try and bring back stuff that I had taken of the poster board. Unfortuantly this did not go as I would have hoped. it still didn't restore the files as it kept the original date when scapping even after I renamed it to the correct year.
apparently it looks like I have to remove all the 15000 + and start all over again unless you know a better way???????????????????????????????????????

You can't continue watching any thing you started as it will start from the start

 

The restore setting in Data Manager only allows you to restore files that you have removed from the posterwall using the "Clean up matching information" context menu in HT.

The bookmark settings define when a file is deemed watched, unwatched or in watching. Default are less than 1 minute = unwatched, less than 3m from the end = watched and anything in between is in watching.

 

Since I do not see me self watching them again for quite a while I'll just leave it as it is.

 

Nothing new. I had the same since the initial release Z9X Pro firmware till this very day. Just check my old posts. The root cause was some specific Polish national characters in the files' names... causing the infinite loop of scanning. I had to remove the file from the drive, rename it to pure English alphabet and put it back.... and only then the infinite loop of scanning was fixed. So some other nationalities characters could have the same impact.

 

Ok, that's a new one on me - not come across that before.

If you can provide some polish (or other) characters that do this I can test and pass to the devs.

 

Hi. As far as I remember the problematic character is ł - Unicode 0142 or ALT 0322, but all should be tested: Ą ą Ż ż Ź ź Ę ę Ś ś Ć ć Ń ń Ó ó Ł ł - https://en.wikipedia.org/wiki/Polish_alphabet

 

Ok - I added the following titles one after the other to HT:

Wisła.mkv
Złoty pociąg.mkv
Wałęsa Człowiek z nadziei.mkv

All three scanned once, were found, and then scanning stopped.

I then added an mkv named randomly:

łagodnieć.mkv

Obviously that couldn't be found as it's not a valid movie title, but again, it scanned, put that mkv into Unmatched and stopped scanning.

 

Hmm, Ok. I will try to reproduce it in few days.

 

i think full flash the media player again download the software then its worked . in my opinion what are you thinking guys......

 

Any solutin for this problem

 

I didn't try to replicate it... But the problem returns without my any "labo" trials...
So what I did:
Powered on Z9X Pro and left it on the start screen without even opening HT. I was even watching TV using different HDMI input, so Zidoo GUI was not at the TV's screen.
From the level of my Windows machine I have created two new folders at the SATA HDD connected directly to the player (via SATA, not USB)... HDD is NTFS formatted. Since the drive is shared via SMB, so it's accessible from Windows.
So I have created those new folders and copied 2 episodes of some TV series to the fist folder... and 4 episodes of another TV series to the 2nd folder. I have done it via two separate copy/paste actions but done one by one. I have waited with the 2nd one till the first paste is finished.
In the meantime (while the 2nd paste process was still copying the very last file) I have switched TV to Zidoo HDMI input to see if all is correctly detected by HT.
I have opened HT and after few seconds it stated to scrap all the new 6 files. It scrapped it all OK, meaning all 6 episodes were correctly recognized adding two new series and including all posters, synopsis etc... No any episode was missing. And no any unmatched files in the relevant section for manual matching.
But again the infinite loop of scraping started... constantly detecting and refreshing HT screen of the files to be processed.
The only way to stop it was to reboot Zidoo or to disable scraping process at the HT sources. Before doing anything I have entered the sources.
What I have noticed that despite of the 2nd batch of pasting of 4 episodes was correctly matched... in the HT sources there is the matched files' count vs the total number of drive files. And the matched files' value was 4 files lower then the total number of files at the source. So the process was looped somehow, since the count of files successfully matched was not updated correctly and system went into the infinite loop of matching even when all files was actually matched.
I have soft rebooted Zidoo. Opened HT and no more matching loop. Entered the HT sources and the counts were still not updated. Still the matched files' value was 4 files lower then the total number of files at the source.
So I have triggered manually to rescan the entire source. And this proces almost instantly (so there was no slow matching with TVDB executed) updated the count and the matched files' value was increased by 4 and both counts shown the same value, meaning all files in the source are matched.
Went back to HT main screen and all was normal - the new TV series as were detected/matched during the infinite loop were still there... and still the unmatched files was empty.
And this time no any Polish alphabet characters in the folder names and file names. Just pure English.

So the observation suggests that the problem is due to the situation that during the matching process the matched files count is somehow not always updated...
Also it might be somehow connected with folders and copy/paste order... since the count was updated correctly for the first 2 files in the 1st folder... but was not updated for the 2nd folder 4 files...
And the last thing - the problem with looped matching was from the very beginning of my unit regardless of the firmware.

 

Sounds like Windows still has a hook on the files and that's causing the rescraping.

 

And how this file lock impacts that the matched files count in DB is not updated? While actually files are matched? This does not add up.
When Windows locks file... it's locked just for updating this very media file, and the file is still available to be read for everyone and to be scrapped and content analysed.. (if not it' wouldn't be possible for the scrapper to perform the streams content analysis of each file before it's fully pasted, but this is what is happening correctly during the file is sill pasting). How windows specific file lock can impact that the count at DB sources is not updated? DB is a different file (even at different internal Zidoo drive), while other DB entries are updated ok.

Your logic would be OK if the entire folder is locked by Windows and Zidoo is actually trying to create some additional temporary file inside this very folder during the process of matching files there. But I haven't noticed that this is the case how Zidoo is acting during matching/scrapping..

 

All I can tell you is that HT monitors the sources and if it perceives the data structure to be changing, it rescans. So whatever Windows is doing is causing that.