WebIf Browse Media Files Really Slow . . .

[Trev]

Nor was I

 

[Black Hole]

Terminal dumps (sounds nasty!)

 

[Trev]

I suspect that you obtusely mean the [ code ] / [/code ]

thingies which are not obvious to find? And do this sort of thing
...
....
....
....
.....
.....
In a scrollable window
End

 

[Black Hole]

My post 19 seems to have gone un-noticed.

 

[neilski]

Aha! OK, sorted it. (Though I did stretch the guidance a bit - I felt the code block formatting wasted a lot of space so because I didn't have much to reformat (thus no need for scroll bars) I just switched font to Courier. Shame the editor doesn't have a button for code blocks btw.)

 

[neilski]

My post 19 seems to have gone un-noticed.

Your idea sounds plausible to me, but best give the OP a chance to reply...

 

[Black Hole]

Shame the editor doesn't have a button for code blocks btw.

It does. Click the document icon to the right of the media icon, select Code, and you get a sub-window to paste the code block into (or type in directly).

Apart from the change of font, the code display block also sections the code / terminal dump off into a frame so that it is obvious to the eye and can be ignored by the disinterested.

I suspect that you obtusely mean the [code] / [/code] thingies

Not all that obtuse - there is a heading in the newbies' guide "Code Listings and Terminal Output". And Trev could do with some tuition in the [plain]...[/plain] tags.

 

[neilski]

It does. Click the document icon to the right of the media icon, select Code, and you get a sub-window to paste the code block into (or type in directly).

Ah, nice, ta. But wow, I would never have found that (how did you?) - I hovered over every button and "Insert..." didn't trigger anything for me. The editor is quite different to what I'm used to on other forums...

 

[Black Hole]

Maybe it's many years of using word processors.

"Insert" is fine, but the strikeout option doesn't belong there.

 

[af123]

Sorry to waffle on so much, out of my depth really, but it's become a personal challenge now to try to get to the bottom of this.
Any help is as always, much appreciated!

It's certainly strange. Everything looks good so far based on what you have posted.
Could you first try running the filecounts diagnostic? That just scans the video area of your disk and shows how many files are in each directory and will also report the start and end time of that process. No need to post the entire output, just see how long it takes and look for any folders with a large number of files.

Secondly, let's try and work out which bit of the media browser is slow. Most web browsers have a way to show each request and how long it takes. With Firefox, you can use Tools->Web Developer->Network to bring up the console and then refresh the browser page. You should get a bar chart showing each request and how long it took.

It will look something like:

and you're looking for a bit that took a long time (or doesn't complete)

 

[Trev]

[rant]

My post 19 seems to have gone un-noticed.

Probably because of your snotogram in post #18

It does. Click the document icon to the right of the media icon,

Yeah, right, really obvious how to do it aint it.
[/rant]

 

[Black Hole]

Call them snotograms if you like (nice coinage!), I'm just trying to educate. How you do it is explained in the newbies' guide.

 

[Trev]

You could have pointed out directly what you consider they have 'done wrong' as well as directing them to the newbie's guide?
How about something like "Please use the code facility for posting terminal dumps etc. in a frame so that it is obvious to the eye and can be ignored by the disinterested. How to do it and other useful stuff is explained in the newbie's guide to the forum etiquette: Newbies' Guide to the Forum (click)".
That would have possibly saved 10 random posts about etiquette in this thread.

 

[Black Hole]

I used to do that. Too much typing (which is why I created the newbies' guide in the first place).

What would improve matters is if the forum software included a means to link to anchor points within posts, in addition to linking to specific posts in their entirety. But it doesn't, which is one way the wiki scores over forum posts.

 

[hy4boy]

Hello everyone, sorry for not getting back here sooner!

Firstly I'd like to apologise for not following the forum rules with regards to posting, certainly not done intentionally and I will endeavour to follow the rules / guidelines the best I can from here on in. Thanks to 'Black Hole' for providing the link to the help page. It was pretty clear to me that my 'dumps' were the focus of the comment so no offence taken there - totally understand the point of view.

And secondly, thank you to everyone who's made a comment or suggestion so far in an attempt to help solve this issue. At time of writing this, it's still there so I'll start to work through all your suggestions this evening and post back the results to all the comments. I certainly won't be ignoring anyone's suggestions.

Thanks again.

 

[hy4boy]

Could you first try running the filecounts diagnostic?

'Filecounts' takes 4 seconds to run - run it a few times to ensure it's consistent and every time is 4 seconds. The file counts of each folder look very consistent with what I would expect too when comparing with how many recordings are in each.

Secondly, let's try and work out which bit of the media browser is slow. Most web browsers have a way to show each request and how long it takes. With Firefox, you can use Tools->Web Developer->Network to bring up the console and then refresh the browser page. You should get a bar chart showing each request and how long it took

A fresh perspective is always good, had tried a different PC but hadn't tried a different browser! Just installed Firefox and when using the WebIf, the problem persists so it's presumably not browser dependant.

Regarding the console, I got the following: (It actually timed out before the media list completed).

 

[hy4boy]

Have you had a look at the disk contents by FTP or SMB (or Telnet ls commands)? Does it look "normal" - ie (usually) a set of four files per recording (.ts, .hmt, .nts, .thm)? There has been a recent report of failed processes creating thousands of orphaned files, which would definitely slow down the media listing!

Thanks for the suggestion, and yes from what I can see using FTP, all the recordings appear to have 4 files associated to each. I certainly can't see any unexplainable files anywhere in any directory.

 

[hy4boy]

it would be interesting to see what you get if you do "ls -l" on it, and if it is a symbolic link, then "ls -lL" on it also, to make it follow the link and see what's at the other end.

This gave me:

humax# ls -l /mod/webif/html/favicon.ico
lrwxrwxrwx    1 root     root            19 Jul 20 19:46 /mod/webif/html/favicon.ico -> img/fav/favicon.ico
humax# ls -lL /mod/webif/html/favicon.ico
-rw-------    1 root     root         10307 Jun 24  2013 /mod/webif/html/favicon.ico

However, if I then dig a little deeper I get:

humax# ls -l img/fav/favicon.ico
ls: img/fav/favicon.ico: No such file or directory

Thanks again for the help - much appreciated.

 

[neilski]

This gave me:

humax# ls -l /mod/webif/html/favicon.ico[...]

OK, that's all precisely what I get on my box, so nothing amiss there (the last one fails simply because it's a relative symbolic link - i.e. it's a path relative to the location of the link itself, hence it points at /mod/webif/html/img/fav/favicon.ico). Even the file has the same size and timestamp. I have no idea why fix-flash-packages threw up those errors.

In the meantime, while others ponder the rest of your diagnostic output, could you see what "df" and "df -i" give? (They show free disk space, and free inodes respectively.) If you have the sysmon package installed, you could also run "top" while the browse window is loading to see if you are CPU-limited...

 

[hy4boy]

'

could you see what "df" and "df -i" give? (They show free disk space, and free inodes respectively.)

humax# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                17536     17536         0 100% /
tmpfs                    62508        60     62448   0% /tmp
tmpfs                    62508         0     62508   0% /media
/dev/mtdblock1            2048       536      1512  26% /var/lib/humaxtv
/dev/mtdblock2            2048       412      1636  20% /var/lib/humaxtv_backup
/dev/sda1              1032088     46116    933544   5% /mnt/hd1
/dev/sda2            1911506492 1410714892 500791600  74% /mnt/hd2
/dev/sda3             10321208    796164   9000756   8% /mnt/hd3
humax# df -i
Filesystem              Inodes      Used Available Use% Mounted on
/dev/root                 1929      1929         0 100% /
tmpfs                    15627        19     15608   0% /tmp
tmpfs                    15627         4     15623   0% /media
/dev/mtdblock1               0         0         0   0% /var/lib/humaxtv
/dev/mtdblock2               0         0         0   0% /var/lib/humaxtv_backup
/dev/sda1                65536        15     65521   0% /mnt/hd1
/dev/sda2            121380864     11120 121369744   0% /mnt/hd2
/dev/sda3               655360        16    655344   0% /mnt/hd3

Again, not totally sure at all the info I'm looking at but I must admit the /dev/root entries with 'all used and zero available' . . . That doesn't sound too good!