Posts by nars

    It's weird really... my idea was that permission to access streams may differ to the one needed to access picons... that's why I told you to check access control permissions, however if you have all permissions enabled for that 'admin' user and if there is no other restrictions for that account at all (like ip based restriction...) then it may be some bug with that tvheadend version... I can't check it now with that version, sorry, but I may test it for you in a few days if you find no solution and no one else comments on this.

    Btw, do you use some special characters for your password? just an idea...

    Not the same problem... sure you have all ok with tvheadend access control permissions? Maybe it needs some specific permission to get icons, that you didn't enable for that user?

    If you don't find why try this on ssh and post the output:

    Code
    curl -o /dev/null -v -m 10 http://USERNAME:[email protected]:9981/imagecache/573


    (replace USERNAME/PASSWORD by the same one you use on kodi tvheadend pvr addon...)

    From my tests (and I do also have 3 RPi's) if I just add port 139 on all of them then I can't experience any kind of problems anymore... only one system will "randomly" win election for master browser (it depends on 'os level' value and uptime) but no issues at all... no conflicts... independently of what one gets master browser it will always work fine... that's why I suggested it to be default.

    If you "force" one of them to be master browser by increasing 'os level' then you may not need to fix config (i.e. add port 139) on any other system(s), as you will know these others will never win the election... and then the problem will not show up (until the day you disconnect the one you set to be always the master browser). Anyway also this sort of config always needs to be applied manually, as it is different on each system... then despite a valid solution no way it can be made the default...

    I did never needed to add wins for name resolution to work... maybe adding it makes it work even without netbios port 139 available? (just a guess, I didn't test that). Anyway again not a solution for default config, requires manual config.

    JFYI, I did test some different versions and here are the results...

    I can reproduce the problem on these:

    - OpenELEC 6.0.3 (curl 7.47.1)

    - LibreELEC 7.0.2 (curl 7.48.0)

    - LibreELEC 7.90.004 (curl 7.49.1)

    - LibreELEC milhouse devel-20160828003726-#0827-g7cef50d (curl 7.50.1)

    - Kodi 17.0 beta1 for Windows (curl 7.48.0)

    I can NOT reproduce the problem on these:

    - OpenELEC 5.0.8 (curl 7.37.1)

    - Kodi 16.1 for Windows (curl 7.42.1)

    At least you can reproduce it, that means I'm not mad or having paranormal issues

    Don't think it's too many connections either, curl just appears to try to reuse them, with max 15 connections apparently (same on windows kodi), but on LE something just goes wrong and they stall until timeout... causing the annoying 10 sec. delays

    I will try to report the non standard HEAD returning contents to TVH guys, maybe that actually fixes it...

    I'm having the issue since OE6 at least, then it's not new at all, I may try LE8 / milhouse soon out of curiosity.

    Thanks CvH for all your help, testing and confirming the problem!

    Just want to add that I did found this is not RPi specific at all. Today I decided to try booting a x86 PC with libreelec 7.0.2 and test it, started with a fully clean config, installed TVH PVR Client plugin, setup it to connect to TVH on my RPi and could reproduce the problem. Then I decided to install TVH also on that new x86 libreelec (thus not depending on RPi or anything else), configured it with my channels and picons... changed TVH PVR Client plugin to connect to local TVH (127.0.0.1)... reboot... tried to browse the channels list on kodi and... I can reproduce the problem!!! I'm attaching the log.

    Btw, I did found one thing that may be related to all this: TVH is replying whole file contents to HEAD requests to imagecache urls (like if it was a GET request), and I notice on logs that kodi does a few HEAD requests... and curl is trying to reuse connections... maybe that puzzles curl (as no contents should be expected) and causes curl to "stall" connections?
    Anyway on kodi for windows curl handles this non-standard thing, and alerts it on log like this "Excess found in a non pipelined read: excess = 4540 url = /imagecache/1115 (zero-length body)", on libreelec version I see no such lines... different curl version doing difference?


    CvH: Sorry to persist, but if you try to clean image cache on tvh, then reboot libreelec (or stop/start tv service on kodi...), then when you browse channels list for 1st time on kodi in libreelec don't you see icons fetching slowly? (just scroll down the list as they apparently fetch as you scroll it) and check if you have lines like these showing on kodi log:

    Code
    00:59:51 T:140085617993472   ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://127.0.0.1:9981/imagecache/703
    00:59:55 T:140085626386176   ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://127.0.0.1:9981/imagecache/799
    00:59:56 T:140085374736128   ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://127.0.0.1:9981/imagecache/702
    01:00:34 T:140085626386176   ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://127.0.0.1:9981/imagecache/732
    01:00:34 T:140085366343424   ERROR: CCurlFile::Stat - Failed: Timeout was reached(28) for http://127.0.0.1:9981/imagecache/791


    (no need to enable debug to see just these)

    Note that it only happens for 1st time kodi is fetching them (and cleaning tvh image cache should force that, as it assignes them different numbers for their imagecache/nnn urls, and the kodi restart I mention is needed after that to get new urls from tvh). After icons fetched then kodi caches them and it will be always fast, until icons change again...

    (there is another way to force kodi re-fetching icons without cleaning image cache on tvh, by just cleaning kodi cache itself, just deleting .kodi/userdata/Thumbnails/ dir and .kodi/userdata/Database/Textures13.db file, restart kodi, then browse channels list and it will fetch icons while scroll)

    If you can't reproduce this... then I guess maybe I should search for paranormal help as I can always reproduce it... on two RPi's, now on x86, multiple clean configs... only on kodi on Windows as TVH client I can't see the problem (but from curl debug log I think there may exist differences on the way curl does requests) or using apache to serve icons then also no problem at all on any kodi client as I said before.

    1. icons work fine on tvh web based epg, and I can tell you that I did already even right clicked image on one of them, clicked 'view image' (to get just the image on the browser) and then hit ctrl+f5 a few times fast to test browser fetching it from tvh, no problems at all in any requests, no delays...

    2. back to srp picons (config changed, reset all icons, clean image cache...), I did tried your 8bit ones and exactly same delays/timeouts fetching them on kodi on RPi.

    I really think we are on the wrong way suspecting about any issue with the image files... again note that the icons always end showing up... there are just curl timeouts (in kodi log) for kodi on RPi fetching them from tvh acting as http server... then kodi (or curl itself) apparently retries the request and eventually succeeds, just very slow waiting for these 10sec timeouts a few times to get all icons...

    I will soon try to enable tvh trace and will post if I find something...

    Ok, I made a small script to create a new set of channel name based icon files (snp) and I can reproduce same exact issue, FYI they also use imagecache/nnn urls (despite image cache is disabled and path is set as 'file:///storage/picons/tvh/%C.png') and the delays/timeouts when kodi on RPi is fetching them are exactly same as for picons (srp).

    Btw I'm curious why I can't see anything on tvheadend log when it is serving icons even with debug enabled and subsystems set to +all... you have any idea? maybe trace debug would show something, but if I understand it needs to be enabled at tvheadend compile, right? If you have any idea I'm ready to do any tests you need.

    Nothing is logged at tvheadend when the problem happens, even with debug subsystems set to +all, anyway I did exactly as you asked, incl reset icons for all channels, then reproduced the problem (i.e. browsing the channels list) and I'm attaching both tvheadend and kodi logs and some screens.

    Btw, I notice on your screen that you use channel icons (channel name based) and not picons exactly... maybe the issue is only with picons? I notice that picons show as picon:// and channel icons show as file:/// in the user icon column in channels list, despite both set as file:///... paths as you can see on config screens, and yes I did reset them.

    Thanks for your reply CvH, concerning your points:

    1. I have "Image Cache" option disabled in tvheadend options (never enabled it in fact), however aparently imagecache is used anyway for local picons (i.e. when "Picons path" set to file://...), if you enable kodi debug you should see what I mean (i.e. requests to /imagecache/nnn urls as in my log).

    2. I did tried tvheadend42 with a clean config and could reproduce same exact problem.

    My picons are very similar to the ones you pointed on srp files, transparent png's, 220x132, same file names format... and yes I did put them at /storage/picons/vdr/ for tvh42 as it is set on it as default path...

    However after you mention imagecache problems I did a few tests more and instead of setting "Picons path" to file://... for local picons I did instead set it to an http:// url pointing to an apache server I have running at another pc at my LAN, and hosted picons on it for sure... the result is that now kodi at RPi fetches them very fast from the apache server! (as it should, and similar to what kodi on Windows always did)

    Also I can tell that yet before trying to host picons at apache I did also compare the debug log (with curl debug enabled) from both kodi running at RPi (with problem) and the log from kodi running at Windows (without problem)... and I could notice that there are apparently differences on the curl way to work... If I can understand corrently for kodi for RPi curl seems to use a pipelining method (to fetch picons faster? but that doesn't happen for sure, it sort of "chokes" instead) while kodi for Windows apparently doesn't do that... that makes me think that CvH may be correct, it may be all down to a bug at tvheadend imagecache code, that is triggered by these request methods from kodi on RPi... just don't know why kodi for Windows is different, but apparently it is, looking at the log... however I may be wrong and it may be just a bug at kodi/curl that doesn't show up when fetching from apache for some reason...

    For now as workaround I will just keep using picons hosted at apache and all is perfect