WebIf Browse Media Files Really Slow . . .

Also... Looks like the fix you proposed for error checking in auto-unprotect is in the latest version - this is what I have:

Code:
humax# cat /mnt/hd2/mod/etc/recmon.d/auto-unprotect 
#!/mod/bin/jimsh

if {[lindex $argv 0] ne "-stop"} exit

source /mod/webif/lib/setup
require ts.class

set file [lindex $argv 1]
set ts [ts fetch "$file.ts"]
if {$ts eq "0"} exit

while {[$ts inuse]} { sleep 30 }

exec /mod/sbin/unprotect "$file.ts"

if {[$ts get definition] eq "HD"} {
        loop i 1 4 {
                sleep 60
                exec /mod/sbin/unprotect --dlna
        }
}

humax#
 
I stand corrected then. Last time I checked it hadn't been.
Are you still getting the errors with this or were you on an old version?
 
OK, so if we take a small sample of the output as below there appears to be a repeat pattern where it pauses . . .

Code:
<img src="/images/172_1_26_SD.png" class="va" height=21 >
-------    PAUSES HERE ------
<img src="/img/compress.png" class="va" height=21  alt="Shrunk" title="Shrunk">

In the pause, it is checking whether the recording is locked, encrypted, has guidance, is DLNA indexed and if it's shrunk.
Of those, my suspicion would be on the DLNA index check. Have you ever reset the DLNA database? If not, give it a try and see if it improves things - follow the link from the Diagnostics page.
 
florca said:
hy4boy - Worth checking whether you have these duplicated / wrongly copied directories and "filebglastop.dat" in your My Videos folder and deleting them?
No such luck I'm afraid - all directories / structures look good as far as I can see.
 
afr123 said:
Have you ever reset the DLNA database?
Yes I have - just done it again too and still no luck.

Re-installed the custom firmware again yesterday and still the problem exists, so I'm currently Ftp'ing all my recordings to another drive and see what happens when the drive is re-formatted using the CF and start making new recordings.
 
Yes I have - just done it again too and still no luck.
That's the only check in the pause that could realistically cause a delay. I suggest commenting those two lines out of the code just to see if it improves the speed.

Edit /mod/webif/html/browse/index.jim (the web interface editor can do it) and find the lines which say:

Code:
  # Indexed
  if {$::model eq "HDR" && [llength [$ts dlnaloc]]} {
  icon "/img/dlna.png" "Indexed by DLNA Server"
  set dlna 1
  }
then put a # character in front of each line and save. That will stop it even attempting the DLNA lookups.
 
Thought I'd add into this thread that I am also having this issue - original hdd though with not a great deal of space left which might be contributing to the slowness. When trying to browse media in the webif it takes literally 3 or 4 minutes to list.

Not going to have much of a chance to do any diagnosing as I get very little time due to a little boy running about...lol but will keep an eye on this thread and try any fixes that might come up.
 
af123 said:
I suggest commenting those two lines out of the code just to see if it improves the speed.

Bit tight for time this evening so can't reply in detail at the moment but just like to say that commenting these lines out does indeed fix this problem! Tried this last night and speed was back to normal.

Will reply properly tomorrow (hopefully!) - Thanks for everyone's help / suggestions so far.
 
That definitely indicates an issue with the DLNA database then but you've already reset that. Can you double check that you did everything in the right order including temporarily turning content sharing off in the standard menus? If so then I'd be interested to see a copy of that database if you could upload it somewhere. The file is /mnt/hd2/dms_cds.db
 
af123 said:
That definitely indicates an issue with the DLNA database then but you've already reset that. Can you double check that you did everything in the right order including temporarily turning content sharing off in the standard menus? If so then I'd be interested to see a copy of that database if you could upload it somewhere. The file is /mnt/hd2/dms_cds.db

Big thanks to you, looks like you've found the problem - not sure if there's possibly a little bug in there but let me explain . . .

Firstly I tried to view the database you referred to via the Database Browser in Diagnostics. The title came up but no data or anything else. From there, I went to the DLNA Server screen.

DLNA Server Status was showing as Disabled / Not Running, and 'Content Share' was off when checking via the box / remote. Can't actually remember ever turning this feature on (it's not something I've ever really dabbled with). Anyway, after turning it on via the remote, the WebIf showed it as Enabled / Running and the Folders / Movies etc. Indexed count started to rise (previously the boxes that show the counts, were empty / missing).

I let this run for a few minutes to complete it's count and it's as simple as that, the WebIf is now back to full speed with the code lines you mentioned all back in and functioning rather than commented out.

I'm guessing for some reason, it doesn't like having this database empty? Not sure if it only ever gets populated once 'Content Share' is turned on or if it should happen regardless of whether it's on or off? So there may still be a question as to why my box had an empty database in the first place?

Either way, big thanks to you all for helping me through this. The massive delays were making the WebIf unusable but now it's back to it's normal self it truly is a fantastic piece of work.

Many thanks and all the best!
 
The number of CF users with Content Share = Off will be minimal, as Content Share = On is a prerequisite for custom decryption. Therefore your situation will not have been encountered very often and it has escaped attention that there is a bug in the WebIF operation under these circumstances. A trap needs inserting in the code to bypass the DLNA index query if Content Share = Off.
 
That sounds fair. Not sure if something has changed as versions have evolved as it was all working fine for a very long time before things went AWOL. Either way, I'm very happy with it again and maybe there's some usual info in this thread for others.

Thanks again to all who contributed!
 
I'm not saying this bug shouldn't be addressed - I was just explaining why it might not have been spotted so far!
 
Back
Top