Tvheadend

My presumption would be that the extjs interface is having a problem with something... though a 404 I'd understand, but not a 400 (bad request vs not found).

My guess would be one of:

1. Permissions and structure of the web interface files. These should be under /usr/share/tvheadend/src/webui/static. Files and directories are root/root; files are 644, directories 755. The error will be emanating from /usr/share/tvheadend/src/webui/static/app/config.js.

2. Permissions/structure/existence of the image cache itself. This is in ~/.hts/tvheadend/imagecache - needs to be accessible to hts/video.

I'm presuming that something's been eaten in your wipeout, maybe referencing cache files that aren't there any more, maybe loading a config that's corrupt.

I'm guessing a lot here, though, and just following my nose...

thank you for replying.

checking item 1 all seems to be ok.

Can I confirm the permission on config.js mentioned in item 1.

however item 2

I don't have a imagecache at all. shall I simple create one?

thanks again for your advise so far.

I've attached a screen shot of the error which may help

Well, there should be no reason to create it if you're not using it. Maybe worth trying, though, although I suspect it's trying to read the config and not simply access the directory.

My webif files, with permissions:

ian@Server:/usr/share/tvheadend/src/webui/static/app$ ll
total 240
drwxr-xr-x  2 root root  4096 Feb 24 13:08 ./
drwxr-xr-x 12 root root  4096 Feb 24 13:08 ../
-rw-r--r--  1 root root  1809 Feb 24 11:03 acleditor.js
-rw-r--r--  1 root root  2337 Feb 24 11:03 capmteditor.js
-rw-r--r--  1 root root  1614 Feb 24 11:03 chconf.js
-rw-r--r--  1 root root  1681 Feb 24 11:03 comet.js
-rw-r--r--  1 root root  6228 Feb 24 11:03 config.js
-rw-r--r--  1 root root  1303 Feb 24 11:03 cteditor.js
-rw-r--r--  1 root root  2913 Feb 24 11:03 cwceditor.js
-rw-r--r--  1 root root 21832 Feb 24 11:03 dvr.js
-rw-r--r--  1 root root  9900 Feb 24 11:03 epggrab.js
-rwxr-xr-x  1 root root 12656 Feb 24 11:03 epg.js*
-rw-r--r--  1 root root  9023 Feb 24 11:03 ext.css
-rw-r--r--  1 root root 38737 Feb 24 11:03 extensions.js
-rw-r--r--  1 root root 24792 Feb 24 11:03 idnode.js
-rw-r--r--  1 root root  6974 Feb 24 11:03 iptv.js
-rw-r--r--  1 root root  2899 Feb 24 11:03 mpegts.js
-rw-r--r--  1 root root  4209 Feb 24 11:03 servicemapper.js
-rw-r--r--  1 root root 11152 Feb 24 11:03 status.js
-rw-r--r--  1 root root  3921 Feb 24 11:03 tableeditor.js
-rw-r--r--  1 root root  3961 Feb 24 11:03 timeshift.js
-rw-r--r--  1 root root   140 Feb 24 11:03 tvadapters.js
-rw-r--r--  1 root root  9493 Feb 24 11:03 tvheadend.js
-rw-r--r--  1 root root  2646 Feb 24 11:03 tvhlog.js
-rw-r--r--  1 root root  6999 Feb 24 11:03 v4l.js
ian@Server:/usr/share/tvheadend/src/webui/static/app$

Now, different matter - you've compiled this yourself to get transcoding, yes? And there's no image caching option on that screen? I wonder if you're switched it off at build time, or if it's been disabled because something was missing... we'd need to check the build scripts, or maybe there's a missing dependency.

One thing I saw on another post - if you can view the page without formatting then you may be able to see the missing text and/or checkboxes. You can't do it in Chrome, but in Firefox it's View -> Page Style -> No Style, then you can scroll down the page or search to see if it's there.

Yes, imagecache is a configure option...

https://tvheadend.org/projects/tvheadend/repository/revisions/master/entry/configure

If you don't need it, you can disable it (--disable-imagecache), otherwise we'd need to see build-time errors to understand why it's not working. It only appears to be dependent on curl (libcurl) - is that installed okay?

sorry imagecache is used for?

Where would the build-time errors be held?

I've checked curl and running the newest version.

From the help text:

Icon caching - this will cache any channel icons or other images (such as EPG metadata). These will then be 
served from the local webserver, this can be useful for multi-client systems and generally to reduce hits on 
upstream providers.

If you don't need it, you could just switch it off.

Any build errors should be shown at configure time or while compiling.

Re: curl, there doesn't appear to be any kind of version dependency, so if you have libcurl then it should be using it unless there's a dependency on a deprecated call or similar (really guessing now!).

that would be kinda of handy really.

As the system is built whats the best option to add the iconcaching in, without starting from scratch.

I appreciate the continued help.

You could frig it.

Since you're building from source, I'm assuming a recent version... I'm also assuming you're running as hts, so modify if needed...

As the hts usee, create this file/directory structure in ~/.hts/tvheadend:

hts@Server:~/.hts/tvheadend$ ls -la 
....
drwx------   4 hts video     4096 Feb 25 20:41 imagecache
...

hts@Server:~/.hts/tvheadend$ ls -la imagecache

drwx------  4 hts video 4096 Feb 25 20:41 .
drwxr-xr-x 17 hts hts   4096 Feb 24 13:08 ..
-rwx------  1 hts video   86 Feb 25 20:41 config
drwx------  2 hts video 4096 Feb 24 13:18 data
drwx------  2 hts video 4096 Feb 24 13:18 meta

Contents of config:

hts@Server:~/.hts/tvheadend/imagecache$ more config
{
        "enabled": true,
        "ignore_sslcert": false,
        "ok_period": 168,
        "fail_period": 24
}

(to disable, set "enabled" to 'false')

I suspect it's this config file that's causing your problems - or the lack of it, anyway.

The other directories should be populated as and if necessary...

Hi, I've done this

root@satserver:/home/hts/.hts/tvheadend/imagecache# ls la
total 20
drwxrwxr-x 4 hts hts 4096 Feb 25 21:02 .
drwxr-xr-x 12 hts hts 4096 Feb 25 21:08 ..
-rw-rw-r- 1 hts hts 114 Feb 25 21:02 config
drwxrwxr-x 2 hts hts 4096 Feb 25 21:01 data
drwxrwxr-x 2 hts hts 4096 Feb 25 21:01 meta
root@satserver:/home/hts/.hts/tvheadend/imagecache#

and still...

2014-02-25 21:08:45.262 api: failed to find subsystem [imagecache/config/save]
2014-02-25 21:08:45.262 HTTP: 192.168.10.24: /api/imagecache/config/save -- 400

I thought you had cracked it then!!

Check permissions - I don't know what UID/GID tvheadend is running as, but it may be that it can't write to the config file or directory now.

If you noticed, it failed on LOAD before, now it's failing on SAVE...

its still

2014-02-25 21:53:34.421 api: failed to find subsystem [imagecache/config/load]

2014-02-25 21:53:34.421 HTTP: 192.168.10.24: /api/imagecache/config/load -- 400

and just tried some other stuff as well...

very frustrating had other questions as well. but wanted to sort the above out first.

drwxrwxr-x 4 hts video 4096 Feb 25 21:43 ./
drwxr-xr-x 12 hts hts 4096 Feb 25 21:08 ../
rw-rw-r- 1 hts hts 114 Feb 25 21:02 config
drwxrwxr-x 2 hts hts 4096 Feb 25 21:01 data/
drwxrwxr-x 2 hts hts 4096 Feb 25 21:01 meta/

thanks for your help this evening, if you think of anything else let me know

hts and root are in the video group.

I'm still pretty certain that we're on the right track... the code in question is:

 imagecache_form.getForm().load({
      url     : 'api/imagecache/config/load',
      success : function (form, action) {
        imagecache_form.enable();
      },
      failure : function (form, action) {
        alert("FAILED");
      }
    });

You can test this by hacking config.js to say "BANANA" instead of "FAILED" .

Now, I haven't traced all the code, but I'm still pretty certain (as above) that this is failing because it just can't read or write to the config file. It's possible that there's a syntax error in the file or something similar, so that's worth checking, but let's be certain that the files are accessible first.

You say that hts and root are in video ... but video doesn't have access to those files... mine are hts/video, yours are hts/hts. Not necessarily the problem, but...

Options if we can't find it:

1. Hack the code in config.js to ignore or over-ride the error
2. Rebuild with --disable-imagecache
3. Rebuild "as is" and see what errors are thrown, because including imagecache clearly didn't work

What platform are you on?

And do you need transcoding?

Hi thanks again for support.

I've changed /usr/share/tvheadend/src/webui/static/app/config.js to

});
imagecache_form.getForm().load({
url : 'api/imagecache/config/load',
success : function (form, action) {
imagecache_form.enable();
},
failure : function (form, action) {
alert("testing");
}
});
});

restarted tvheadend, and still came up with failed. screen shot attached.

I would love transcoding, as the main reason for changing was so I can use my mobile as the upload on my connection isn't great.

Okay, I'm stumped. I can't imagine that the error is coming from anywhere else, unless you're running tvheadend under a different user, or haven't installed it in the same way as you did previously? Something is generating that message, and I don't know what.

cd /
grep -r "imagecache" .

?

Might just be a process of elimination to find what's generating that error... is it possible that you've compiled but not installed, so have the files in your home directory and they're not accessible to the hts user (e.g. if you've compiled as yourself but are launching it with -u <user>)?

Is that worth trying - forcing tvheadend to run as hts, or as root, or as yourself, or wherever else you have config files? I wonder whether we've been looking in the wrong place...

Have any of the timestamps changed on any files in .....hts/tvheadend since you rebuilt?

I've also been having the same problem for a while now.

I've done a rebuild with --disable-imagecache but doesn't clear the FAILED error.

I think I've done it right with ./configure --disable-imagecache ?

I've checked permissions in /home/hts/.tvheadend and everything seems OK. hts:video which is what tvheadend is running under.

It seems like it should be a simple fix but I'm stumped :S

As above - we'd need to find where the error is coming from. The scripts are editable, so it's easy to change the error message and trace which bit of which code is throwing the problem.

I'm not convinced that there aren't two different versions of tvheadend floating about (for example), one in the normal /usr/share... location and one in a build directory. Starting tvheadend as a normal user doesn't have access to the former; starting it as hts doesn't have access to the latter. That could throw the error (although it doesn't fully explain why one file would be less readable than any other).

So that'd be my path... find all the .js files that contain FAILED, and change each occurrence to FAILED-<file&path>, something like that. When you get the message, you can perhaps print out the variables at that point (to see if something's gone wrong) or trace through the logic to see what file is(n't) being opened.

Yeah I was able to change the error message by editing the relevant line config.js file although the path on my Ubuntu setup is in /usr/local/ e.g. /usr/local/share/tvheadend/src/webui/static/

As for permissions this is my ls -al output:

drwxr-xr-x  2 hts video  4096 Feb 28 01:43 .
drwxr-xr-x 11 hts video  4096 Feb 28 01:43 ..
-rw-r--r--  1 hts video  1809 Feb 28 01:43 acleditor.js
-rw-r--r--  1 hts video  2337 Feb 28 01:43 capmteditor.js
-rw-r--r--  1 hts video  1614 Feb 28 01:43 chconf.js
-rw-r--r--  1 hts video  1681 Feb 28 01:43 comet.js
-rw-r--r--  1 hts video  6228 Feb 28 10:46 config.js
-rw-r--r--  1 hts video  1303 Feb 28 01:43 cteditor.js
-rw-r--r--  1 hts video  2913 Feb 28 01:43 cwceditor.js
-rw-r--r--  1 hts video 21832 Feb 28 01:43 dvr.js
-rw-r--r--  1 hts video  9900 Feb 28 01:43 epggrab.js
-rwxr-xr-x  1 hts video 12656 Feb 28 01:43 epg.js
-rw-r--r--  1 hts video  9023 Feb 28 01:43 ext.css
-rw-r--r--  1 hts video 38737 Feb 28 01:43 extensions.js
-rw-r--r--  1 hts video 24792 Feb 28 01:43 idnode.js
-rw-r--r--  1 hts video  6974 Feb 28 01:43 iptv.js
-rw-r--r--  1 hts video  2899 Feb 28 01:43 mpegts.js
-rw-r--r--  1 hts video  4209 Feb 28 01:43 servicemapper.js
-rw-r--r--  1 hts video 11152 Feb 28 01:43 status.js
-rw-r--r--  1 hts video  3921 Feb 28 01:43 tableeditor.js
-rw-r--r--  1 hts video  3961 Feb 28 01:43 timeshift.js
-rw-r--r--  1 hts video   140 Feb 28 01:43 tvadapters.js
-rw-r--r--  1 hts video  9493 Feb 28 01:43 tvheadend.js
-rw-r--r--  1 hts video  2646 Feb 28 01:43 tvhlog.js
-rw-r--r--  1 hts video  6999 Feb 28 01:43 v4l.js

Have you changed the install path at all? Just wondering why you're in /usr/local and I'm in /usr/share.

Could you have two configs floating around at all, not just /home/hts/.hts?

Not sure why I'm I have a different path. I recently did a completely fresh install (format & start again etc) of my system when moving from Ubuntu 12.04 to 13.04. Compiled & installed tvheadend from git using this https://tvheadend.org/projects/tvheadend/wiki/Building as a guide/reminder.

Maybe it's a distro thing - I'm on 12.04 still until 14.04 comes out. I always build a package and install from there, so maybe that's relevant.

Have you checked that you've only one set of config files? It feels to me - and I'm sounding like a stuck record here, but I obviously can't test it myself - that the tvheadend process is throwing that error when the .js files try to locate the imagecache files. These should be in the .hts/tvheadend/imagecache folder, but if something's pointing to the wrong place or if ownership has changed (e.g. UID of the process, or built to run in a non-standard location) then that would explain the error.

If it's not that, though, I'm not sure what to suggest without hacking the code to do some debugging.

ok looking at both posts I do have another location of tvheadend

/usr/local/share/tvheadend

/usr/share/tvheadend

so therefore if I change the below config.js to testing rather than failed it does come up on as testing when going into configuration

/usr/local/share/tvheadend/src/webui/static/app/config.js

so as I've found the file what testing can I do to solve the original error?

Thanks again.

slight process if I run

/usr/local/bin/tvheadend as hts the /api/imagcache/config/load disappears and doesn't give the failed or as its now testing message however trying to save any changes comes up with the below, what permissions should this have? and how can I get tvheadend to run as hts at the start up rather than the root?

2014-03-01 15:28:13.194 api: failed to find subsystem [imagecache/config/save]

2014-03-01 15:28:13.194 HTTP: 86.5.59.36: /api/imagecache/config/save -- 400

thanks guys although a simple config issue I feel I understand the simple slightly more jsut this last bit

I guess the next step is to find out what that config.js is trying to access, and why it can't.

What UID/GID is tvheadend running as? ps -eaf | grep tvheadend

Are there any other configs lying around? find / -name tvheadend -print or find / -name imagecache -print or accesscontrol or anything else that's going to uniquely point to a tvheadend configuration directory.

After that, I'd look at the config.js and see whether there's some way of printing out the file it's trying to access. I'll take a look, but I know nothing about Javascript, so I'd be floundering. I wonder if you use a browser like Chrome, and switch on the Javascript console, whether you'll see a more useful error message when you navigate to this particular page?

Crossing messages...

1. How you change the user is dependent on how you start it. If you're starting as root, though, you probably have another .hts/tvheadend directory in root's home folder.

2. If you're starting from init, it would normally start under the right user.

3. If you're starting it otherwise, use /usr/bin/tvheadend -f -u hts -g video

-f - forks into a daemon and runs in the background
-u - UID
-g - GID

I need to think about why you can't save it...

Okay, you gave your original permissions as:

drwxrwxr-x 4 hts hts 4096 Feb 25 21:02 .
drwxr-xr-x 12 hts hts 4096 Feb 25 21:08 ..
-rw-rw-r- 1 hts hts 114 Feb 25 21:02 config
drwxrwxr-x 2 hts hts 4096 Feb 25 21:01 data
drwxrwxr-x 2 hts hts 4096 Feb 25 21:01 meta

Sooooo....

IF you're using these files then there's still something wrong with the permissions. You have 'config' globally-readable, which would explain why it can be... well, read; however, it's only writeable to hts:hts. If you're running as anything else, that would explain the write error.

It looks to me like something's borked on your installation... having two configs floating around isn't a good thing. If I wanted to be certain, I'd nuke it all and start again. Maybe the ghosts of your "messing around too much" are still haunting you :-)

I can't remember if you said what platform this is on... if it's Debian or 'buntu, I'd wipe it and build a .deb, and reinstall from there.