[MidKnight]

the unpacking is because your using compression. use non and it play without needing to unpack first. this has always been the case.

but otherwise it is working as before, only expect this new issue if the kodi has been rebooted

not sure why your not getting the files listed though?

are you on irc anywhere, we can catch up there if you are?

[MidKnight]

also I see your using the newer file format, part1 etc.. which seems to be a problem too. use the old school format of *.rar01, *.rar02 etc

[Milhouse]

the unpacking is because your using compression. use non and it play without needing to unpack first. this has always been the case.

but otherwise it is working as before, only expect this new issue if the kodi has been rebooted

not sure why your not getting the files listed though?

Not sure, I get the same behaviour on RPi2 and Generic builds of LibreELEC.

RAR files are not something I've used before so perhaps there is something wrong with my test files (although with #0408 they are working), but to be honest I'm not that fussed if it doesn't work - it's not my problem (yeah, shitty attitude I know). If developers aren't interested in supporting/testing their work then they can deal with it once it is released.

are you on irc anywhere, we can catch up there if you are?

I'm on #libreelec (freenode irc) but it's not really something I monitor.

[SpokV]

Pvr iptv simple client library could be loaded on startup.

[Milhouse]

Pvr iptv simple client library could be loaded on startup.

Thanks. Looks like the addon has been bumped before a corresponding kodi dependency has merged:

Code:

05:38:40.327 T:1943382096 WARNING: Unable to resolve: /pvr.iptvsimple.so.3.0.2 ADDON_HasSettings, reason: /usr/lib/kodi/addons/pvr.iptvsimple/pvr.iptvsimple.so.3.0.2: undefined symbol: ADDON_HasSettings

The latest pvr.iptvsimple addon now needs PR12011.

Unfortunately several other addons also require the methods that are to be removed by PR12011 (eg. inputstream.adaptive, peripheral.joystick) and will require updating so it's not possible to include this PR12011 change just yet.

I'll temporarily revert the latest pvr.iptvsimple change in the next build until the situation becomes clearer. Things could get a little rough for a few days...

[doveman2]

Addons - Install from Zipfile isn't working for me. Nothing happens when I Select it but the other options (Install from Repo, My Addons) all work.

This was happening with LE 8 #201 so I updated to #426 but still the same problem http://sprunge.us/igLB

I see in the log:
05:28:56.008 T:1943388160 DEBUG: LIRC: Update - NEW at 33266:1c 0 KEY_ENTER devinput (KEY_ENTER)
05:28:56.008 T:1943388160 DEBUG: OnKey: 11 (0x0b, obc244) pressed, action is Select
05:28:56.009 T:1943388160 ERROR: Keymapping error: no such action 'runaddon()' defined
05:28:56.009 T:1943388160 DEBUG: ExecuteXBMCAction: Tried translating, but failed to understand RunAddon()

which is probably when I'm trying to select Install from Zipfile but I don't know why Select should be triggering 'runaddon()' on that option but not on anything else.

Incidentally, is there anything I can do to stop the "DEBUG: NFS:" messages appearing in the log, as they're so numerous it makes it difficult to see the important events?

[Milhouse]

Addons - Install from Zipfile isn't working for me. Nothing happens when I Select it but the other options (Install from Repo, My Addons) all work.

The "Install from Zip file" home screen widget has never worked.

If you want to install from a zip file, use Addons > Add-on browser > Install from zip file

Incidentally, is there anything I can do to stop the "DEBUG: NFS:" messages appearing in the log, as they're so numerous it makes it difficult to see the important events?

You could always use

Code:

tail -f kodi.log | grep -v "DEBUG: NFS:"

as that will filter out those messages.

However your NFS configuration is the reason the context refresh messages are spamming the log.

For instance:

Code:

05:28:34.586 T:1604920224   DEBUG: NFS: Refreshing context for 192.168.1.64/Media, old: 9042, new: 11845
05:28:34.586 T:1604920224   DEBUG: NFS: Using cached context.
05:28:34.700 T:1604920224   DEBUG: NFS: Refreshing context for 192.168.1.64/Torrents, old: 9063, new: 11959
05:28:34.700 T:1604920224   DEBUG: NFS: Using cached context.
05:28:35.219 T:1697194912   DEBUG: NFS: Refreshing context for 192.168.1.64/Media, old: 11845, new: 12478
05:28:35.220 T:1697194912   DEBUG: NFS: Using cached context.
05:28:35.965 T:1487287200   DEBUG: NFS: Refreshing context for 192.168.1.64/Torrents, old: 11959, new: 13223
05:28:35.965 T:1487287200   DEBUG: NFS: Using cached context.

and then the above repeats a *lot*.

It looks like you have two NFS shares, and Kodi maintains only a single NFS context. When you're requesting information from Media and then from Torrents, and then again from Media, and then again from Torrents, Kodi is continually having to refresh it's single NFS context (which then spams the debug log).

Perhaps if you had a single NFS export, eg. 192.168.1.64/share, and then within your "share" export you have Media and Torrents directories, so that Kodi can access all of the content via a single NFS context.

However I don't really know if refreshing the NFS contexts is a particularly "expensive" (time consuming) process, so it may not be worthwhile and you'll just have to put up with the debug log spam.

[skylarking]

#0408 - native rar support dropped in #0409.

thanks Milhouse, Why was it pulled, its been with xbmc since the early xbox days?, do you know if multi rar support is going to come back?

As per the title of PR11912 included in #0408, it's cleaning up (ie. removing) native functionality that can instead be provided by addons.

Since #0412 I've been including the vfs.rar addon - disabled by default - which in theory should allow you to access rar content, however it doesn't seem to work as far as I can tell.

As of build #0424, sftp is now in the same boat as rar - native support removed, replaced by the vfs.sftp addon (included in the build, disabled). I've no idea if it works or not, as I'm unable to test it.

I'll include the latest versions of vfs.rar and var.sftp in these builds, however if there's no interest in supporting these add-ons from the developer or anyone that submits PRs on his behalf that removes native functionality for non-working add-ons, then I don't think I'll bother including them for much longer. Spiff asked me to include the sftp and sacd add-ons the other day, so let's see how that goes.

To see native functions removed and migrated to an add-ons seems OK on the surface.
And if the end result is a cleaner code base that supports aded features, it can only be a good thing.
However, when there seems to be a waning desire for the coders to actually keep the functionality that made Kodi what it is, it becomes a little concerning as to what lovers of Kodi will end up with.

And yes, 'waning desire' is speculation on my part as 'i know nothing' about how the team coordinates the tasks at hand, nor the people involved.
I know it's open source and all, but i'd have thought as part of a cleanup and add-on migration activities, the coders actually removing stuff would have at least migrated the functionality into an add-on and verified that the functionality they moved still works.

It just seems odd to me that code and thus functionality can be so easily removed, a wild west of coding as such with an obvious end result of a loss of functionality.

@millhouse, i don't believe it's an issue of your making and do appreciate your efforts in providing these edgy LE PRi builds.
If your not too busy, maybe you can enlighten me as to why this is happening and what features we may fall from the table?

[Kougami]

Seems "Adjust display refresh rate: Always" cause the very low free gpumem.

Playing my testfile 4x with disabled "Adjust display refresh rate":
bcmstat: https://pastebin.com/Km8syTLS


Playing my testfile 4x with always "Adjust display refresh rate":
bcmstat: https://pastebin.com/DWqiq6RC
log: http://sprunge.us/DAaF

Thanks, this has been reproduced and a fix should be in tonight's build (which should be available in an hour or two from now).

I can confirm with #0426, my issue is fixed. Thanks.

[asavah]

To see native functions removed and migrated to an add-ons seems OK on the surface.
And if the end result is a cleaner code base that supports aded features, it can only be a good thing.
However, when there seems to be a waning desire for the coders to actually keep the functionality that made Kodi what it is, it becomes a little concerning as to what lovers of Kodi will end up with.

And yes, 'waning desire' is speculation on my part as 'i know nothing' about how the team coordinates the tasks at hand, nor the people involved.
I know it's open source and all, but i'd have thought as part of a cleanup and add-on migration activities, the coders actually removing stuff would have at least migrated the functionality into an add-on and verified that the functionality they moved still works.

It just seems odd to me that code and thus functionality can be so easily removed, a wild west of coding as such with an obvious end result of a loss of functionality.

@millhouse, i don't believe it's an issue of your making and do appreciate your efforts in providing these edgy LE PRi builds.
If your not too busy, maybe you can enlighten me as to why this is happening and what features we may fall from the table?

You should be aware that these excellent @Milhouse's builds are bleeding edge, and are based on current master code, which may contain bugs and regressions, that's why these builds exist - to help the devs hunt the bugs long before new code hits the rest of the users who use release versions.
Eventually new binary addons replacing built-in functionality will be fixed. AFAIK there is huge rework of addon related code incoming, so it may be inefficient to spend developer time now to fix/improve this stuff. We'll have to wait.

If you want stable non-breaking functionality - use releases, but if you want to help Kodi become better and better by testing 0day stuff you may have to suffer a breakage or two from time to time

[popcornmix]

Hi. I've uploaded crashlog from 420,421. Happens when streaming video via network.419 works fine.
It seems to do with the ffmpeg buffer increase. Not sure...

Can you confirm if this crash still occurs with latest build?
I think it will be resolved in tonight's build (when ffmpeg buffer increase is reverted) but there is a possible fix in last night's build we'd be interested in knowing about.

[SpokV]

Hi. I've uploaded crashlog from 420,421. Happens when streaming video via network.419 works fine.
It seems to do with the ffmpeg buffer increase. Not sure...

Can you confirm if this crash still occurs with latest build?
I think it will be resolved in tonight's build (when ffmpeg buffer increase is reverted) but there is a possible fix in last night's build we'd be interested in knowing about.

I've checked on today's build and it's still there. I'll check the tonight's build too.

[doveman2]

The "Install from Zip file" home screen widget has never worked.

If you want to install from a zip file, use Addons > Add-on browser > Install from zip file

Thanks, that did the trick.

I'm still not having any luck with TVheadend using #426 with your TVheadend build #426 though. lsusb shows my tuner is recognised

Bus 001 Device 005: ID 1b80:e409 Afatech IT9137FN Dual DVB-T [KWorld UB499-2T]
Bus 001 Device 007: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 006: ID 046e:5577 Behavior Tech. Computer Corp.
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

but no tuners are listed in the browser GUI (http://192.168.1.85:9981) under Configuration - DVB Inputs - TV Adapters.

There's some errors in the log about TVheadend Client but I don't think they matter at the moment, it's the service I'm having problems with.

http://sprunge.us/DBWN

It looks like you have two NFS shares, and Kodi maintains only a single NFS context. When you're requesting information from Media and then from Torrents, and then again from Media, and then again from Torrents, Kodi is continually having to refresh it's single NFS context (which then spams the debug log).

Perhaps if you had a single NFS export, eg. 192.168.1.64/share, and then within your "share" export you have Media and Torrents directories, so that Kodi can access all of the content via a single NFS context.

However I don't really know if refreshing the NFS contexts is a particularly "expensive" (time consuming) process, so it may not be worthwhile and you'll just have to put up with the debug log spam.

Ah, OK. I'll limit it to one NFS share then. Even if it's not causing any resource issues, I'd like to stop the log spam occurring.

[bkuhls]

So are you happy with the last ffmpeg 3.3 build?
Hopefully we'll be returning to that soon (maybe tonight) as we have some possible audio fixes.

Hi,
do you mean the patch "AESinkPULSE: Return to PA's delay infrastructure"?

If yes, then I can say that backporting this patch to Krypton fixed the
audio crackles with ffmpeg-3.3 Imho this patch should be backported
to Krypton.

[SpokV]

Hi. I've uploaded crashlog from 420,421. Happens when streaming video via network.419 works fine.
It seems to do with the ffmpeg buffer increase. Not sure...

Can you confirm if this crash still occurs with latest build?
I think it will be resolved in tonight's build (when ffmpeg buffer increase is reverted) but there is a possible fix in last night's build we'd be interested in knowing about.

I've checked on today's build and it's still there. I'll check the tonight's build too.

It seems that 427 solved this issue. I'll continue run it and update for any change...thanks