Queue listing has failed; permanent "loading queued data".

boris

boris

New Member
Not sure whether it was a crash of the system, it has had a few of those recently, or a package update. The series of daily crashes seems to have stopped as quickly as it started. I've installed the temperatur and fan packages just in case it's that - it hasn't been that hot around here of late!!

Capture.PNG

I've managed to persuade the decrypting and shrinking to continue, so my thoughts are that it's a display problem, not the back end.

I did notice that, through reinstalling the webif, that there are a few bugs in my local code and there was a package it was failing to find (xconv). I installed them - couldn't find them in the listings but found them manually in the wiki; no improvement. Perhaps the ext2 (or ext3?) fs has been corrupted and take some of the code out but reinstalling the Webif shoudl correct that.

I can't find anything interesting by searching on "queue" in the forums, which again leads me to believe it is my end.

Any musings greatfully received!
 
Thank you MymsMan; I've just become one of those people that utters the inevitable sentence "I swear blind.."!

The webif-error.log file was blank when I made the initial post. I am convinced I saw a few lines of error, with one interesting one at the bottom, in there yesterday. And it is clear (meaning 0 bytes) once again today. Does it really get cleared out, rather than appended to??! WTF!
It says last modified about 2 hours ago and there is a star/asterisk next to the name so I know it was changed. And I know I wasn't fat-fingering something in the console because I was at my own desk fixing something else until a few moments ago.

I know there was something interesting in yesterday night, I had Assistant remind me to look this morning.
Sadly I don't remember much about that all important message. There was something about a file or database being of the incorrect format. That can't quite be true because the back-end queueing is working - there are a whole load of new ad-free, 45 minute sessions of joy there this morning ( I've got a thing for old 'Law & Order' series at the moment and it isn't just anorexic Abby, the shrink or Lenny's one-liners; don't judge me! ).

OK. I get it. Quite a few of the logs are stored in /tmp ( not /../mod/tmp, or even /var/log/ )!! That's a rather unique way of logging stuff.
I'm stuck MymsMan; auto.log ( which isn't in /tmp/ !!) didn't seem to note anything of interest.

FRUSTRATED!
 
Off-Topic to Black Hole : I'm in Bucks. It's been about 20C here inside at 'boris Towers' for the last few days.
Using the temp and monitoring packages, installed a few days ago. Setting the minimum fan to 35% seems to skate close enough to the wind to get away with hammering the machine without going over the 50C sirens and emergency calls to the local constabulary. I have the sweeper deal with adding things to the queue and consequently "DetectAds", "Auto-Processing" may not resemble yours.
It was 40% minimum fan but there are several instances of Chiroptera and Canine in my ancestry.
YMMV.

PS - The Auto Processing package is a real sweetheart. My complements to the dev. Abby didn't like shrinking and decripting whilst other stuff was being recorded.
 
Last edited:
My bad? You were asking/advising about the temparature affecting the frequency of crashing (elsewhere)?
 
It helps not to scatter a conversation across different threads! But in any case, I don't think I was - there has been a mention of a tuner module getting hotter than normal, and the OP thought the best thing to do was hack a hole in the case rather than check the original fitted cooling was working!
 
Black Hole said:
It helps not to scatter a conversation across different threads! But in any case, I don't think I was - there has been a mention of a tuner module getting hotter than normal, and the OP thought the best thing to do was hack a hole in the case rather than check the original fitted cooling was working!
Click to expand...
Fair point. Apologies.
 
boris said:
The webif-error.log file was blank when I made the initial post. I am convinced I saw a few lines of error, with one interesting one at the bottom, in there yesterday. And it is clear (meaning 0 bytes) once again today. Does it really get cleared out, rather than appended to??! WTF!
Click to expand...
Yes, the webif-error log is cleared at start up because the web server starts early during the boot sequence.

The best thing is to go to the queue display and check that the error is still occurring and then go to the diag page to look at the error log.
If you still have the display error but the webif-error.log is empty then the process hasn't thrown a loggable error in which case you may need to to look at your web browser's console log to see what shows up when you view the Queue display page
 
Managed to catch a log whilst it was still logged.
Looks as if the code is looking at the
/mod/etc/webif.db is that right?
That file doesn't look very happy.

humax# stat /mod/etc/webif.db
File: /mod/etc/webif.db
Size: 7168 Blocks: 16 IO Block: 4096 regular file
Device: 802h/2050d Inode: 44993041 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-09-28 01:10:41.000000000
Modify: 2017-09-28 00:56:10.000000000
Change: 2017-09-28 00:56:10.000000000

but the database browser doesn't / can't dump it.

Am I looking in the right place?
 

Attachments

  • Capture.PNG
    Capture.PNG
    50.3 KB · Views: 9
You could try making a new webif.db and preserving what can be saved from the corrupt one:
Code: 
humax# cd /mod/etc
humax# mv webif.db webif_old.db
humax# sqlite3 webif_old.db ".dump" | sqlite3 webif.db
humax# rm webif_old.db
 
Thank you prpr! Much appreciated.

I did that with the queue database but not with the webif. I thought it too dangerous (if the webif relied on records within the database and they won't convert because they are corrupt..)
Losing the queue wasn't such a risk compared to the main interface.
--
I only got two errors; was expecting more.
Duplicate key.

Should all the databases in the database section of diagnostics, provide a display, or are some no longer in use?
For example, detectads.log doesn't seem to be in use any longer, since about January this year.

edit: rather rudely, I didn't say thank you!
 
Last edited:
boris said:
Thank you prpr! Much appreciated.
Click to expand...
Is your queue processing working now then?
Should all the databases in the database section of diagnostics, provide a display, or are some no longer in use?
Click to expand...
Some of them are empty but should display something of their table structure (apart from default_channel.db which really is useless).
For example, detectads.log doesn't seem to be in use any longer, since about January this year.
Click to expand...
Huh? You were talking about databases and then switched to logs.
edit: rather rudely, I didn't say thank you!
Click to expand...
That's OK. Just click the Like link instead :D.
 
Just reporting back: queue listing faithfully restored!
Many thanks prpr.

Didn't see the 'like' link. Done!

One last problem: I need to change my aerial to point to Oxford rather than Bedfordshire.
Have looked in settings, but no luck.
There's the preferred region in the tunefix, yours I believe, but I need something a little more rooted in the physical.
Any ideas where it would be? Pretty please?
 
Last edited:
There's a setting for azimuth, but it involves use of a ladder.

Alternatively, if there is an appropriately located tree, you could try covering it with Bacofoil.
 
I suspect what BH is implying is to move the aerial to point to your chosen transmitter, do an auto retune and see what happens. Do you have any sort of signal meter to assist alignment of the aerial, as trying to do it with one person watching a meter (the Hummy sig strength/quality) and someone else swinging off the aerial is notoriously difficult.
 
I've obviously missed something subtle.
Other than the possibility of blanking out the signals from Sandy Heath without re-positioning the aerial?
 
You must log in or register to reply here.
Back
Top