Kodi Community Forum
v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
+---- Thread: v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) (/showthread.php?tid=298461)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - MidKnight - 2017-04-27

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?


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - MidKnight - 2017-04-27

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


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - Milhouse - 2017-04-27

(2017-04-27, 04:28)MidKnight Wrote: 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.

(2017-04-27, 04:28)MidKnight Wrote: 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.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - SpokV - 2017-04-27

Pvr iptv simple client library could be loaded on startup.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - Milhouse - 2017-04-27

(2017-04-27, 05:59)SpokV Wrote: 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... Sad


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - doveman2 - 2017-04-27

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?


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - Milhouse - 2017-04-27

(2017-04-27, 07:40)doveman2 Wrote: 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

(2017-04-27, 07:40)doveman2 Wrote: 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.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - skylarking - 2017-04-27

(2017-04-27, 01:49)Milhouse Wrote:
(2017-04-27, 01:18)MidKnight Wrote:
(2017-04-26, 21:34)Milhouse Wrote: #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.
(2017-04-27, 03:14)Milhouse Wrote: 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?


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - Kougami - 2017-04-27

(2017-04-26, 22:51)Milhouse Wrote:
(2017-04-26, 11:19)Kougami Wrote: 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.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - asavah - 2017-04-27

(2017-04-27, 09:46)skylarking Wrote: 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 Tongue


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - popcornmix - 2017-04-27

(2017-04-22, 10:51)SpokV Wrote: 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.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - SpokV - 2017-04-27

(2017-04-27, 14:44)popcornmix Wrote:
(2017-04-22, 10:51)SpokV Wrote: 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.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - doveman2 - 2017-04-27

(2017-04-27, 08:09)Milhouse Wrote: 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

Quote: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.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - bkuhls - 2017-04-27

(2017-04-25, 12:40)popcornmix Wrote: 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 Smile Imho this patch should be backported
to Krypton.


RE: LibreELEC Testbuilds for RaspberryPi (Kodi 18.0) - SpokV - 2017-04-27

(2017-04-27, 16:46)SpokV Wrote:
(2017-04-27, 14:44)popcornmix Wrote:
(2017-04-22, 10:51)SpokV Wrote: 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