Kodi v18 (Leia) testbuilds

[Nachteule]

Ok, was working on that issue today (pew)

It is much more complicated than expected, but it's not in Kodi itself, issue is in XBian-config module, probably old issue triggered by new Kodi

Got a working solution now, but has to be more tested

For a workaround, you can do following steps:

1) Disable 'Allow remote control from applications on this system'
2) Stop Kodi
3) Start Kodi
4) And finally you can enable both 'Allow remote control' settings

After more testing, I'll put a new xbian-package-config-xbmc into staging area for testing (probably tomorrow evening)

[dgarciam]

(2nd Feb, 2019 10:54 AM)Nachteule Wrote:  Ok, was working on that issue today (pew)

It is much more complicated than expected, but it's not in Kodi itself, issue is in XBian-config module, probably old issue triggered by new Kodi

Got a working solution now, but has to be more tested

For a workaround, you can do following steps:

1) Disable 'Allow remote control from applications on this system'
2) Stop Kodi
3) Start Kodi
4) And finally you can enable both 'Allow remote control' settings

After more testing, I'll put a new xbian-package-config-xbmc into staging area for testing (probably tomorrow evening)

Thanks a lot! will try right away!

EDIT: It works! thanks a lot!

[BreadPit]

The staging repo upgrade (all packages, not just Kodi18) solved the "menu is black when TV turned off during LiveTV playback". But several other bugs seemed to arise:

"Sync Playback to Display": if enabled, audio is broken. No sound.

2nd issue: sometimes after reboot, screen resolution and/or efresh rate change. I could only choose from very few options with 50/60 Hz only, after reboot I could then change back to 1080p / 24Hz.

All experienced within the first hour of trying. Seems quite buggy... Anyone else having similar behavior?

[Don Pedro]

(14th Apr, 2018 06:51 PM)Nachteule Wrote:  3) XBian is using BTRFS with LZ4 compression for root partition, so usually you can't read this partition from a standard (windows) system

??? Didn't know you could convince Windoze to access BTRFS!

Whatever, LZ4 is causing problems as almost all Linux systems don't include support for it on BTRFS. The result is always the same, an attempt to mount such an SD card will be rejected with a message that a feature bit is set in the file system that's not supported and you'll end up with a file system that can be read/written excusively by Xbian. I'm wondering why this patch had been included at all (on contrary to all other major distros). It couldn't be size, if the card is too small, well then buy a bigger one, they're not that pricey these days.

I once had the problem that for some unknown reason the BTRFS on the card I use for my Raspi got corrupted (which normally shouldn't happen at all, at least that's why we use a journalling FS). The Raspi did no longer boot from it, it got stuck in the very early boot phase with a respective error message begging for Btrfsck, not giving me a console to trigger that. Probably Btrfsck would've repaired the issue, maybe also a rollback to an older snapshot would've been required, but it should've been possible to reset the FS to a consistent state in a couple of minutes. However the Raspi has no second SD card slot so I couldn't trigger the check from another running helper xbian (couldn't find out if it would've been possible to change the card on the fly). I have a debian machine with tvheadend but it doesn't support LZ4, so I couldn't do the check there. I tried booting a couple of live distros, no success. Finally I got rather pissed with fruitless attempts of fishing around and I decided it will be quicker to simply reinstall xbian. It was in fact faster, however on a Raspi with no additional HDD attached xbian will not do any system backups and the corrupted FS including the snapshots was inaccessible. So I ended up with manualy repeating the complete configuration (which didn't raise my mood).

After making this lousy expierience and lots of cursing I additionally installed syncthing on xbian which I use for backing up all my other machines. It allows me to online sync any changed files to a backup machine which runs nightly dirvish hardlink backup, thus no more manual reconfiguring an xbian installation anymore. So you might understand that in my impression adding LZ4 to BTRFS without any other major distro supporting it is a big peeve and it is unclear to me why there was any neccessity at all to have that feature in the file system.

BR

Don

[Nachteule]

@BreadPit

(4th Feb, 2019 06:04 AM)BreadPit Wrote:  The staging repo upgrade (all packages, not just Kodi18) solved the "menu is black when TV turned off during LiveTV playback". But several other bugs seemed to arise:

"Sync Playback to Display": if enabled, audio is broken. No sound.

2nd issue: sometimes after reboot, screen resolution and/or efresh rate change. I could only choose from very few options with 50/60 Hz only, after reboot I could then change back to 1080p / 24Hz.

All experienced within the first hour of trying. Seems quite buggy... Anyone else having similar behavior?

Could you please give us more information about your system!

Which Pi?
sd-card installed?
Debug Logs
Infos about video(s) thad did not play correctly

Today I found a strange issue: when booting from network without sd-card installed (Pi3B+), Kodi can not detect resolution and sets it to 0x0p. Maybe you have same issue

[Nachteule]

(4th Feb, 2019 07:18 PM)Don Pedro Wrote:  

(14th Apr, 2018 06:51 PM)Nachteule Wrote:  3) XBian is using BTRFS with LZ4 compression for root partition, so usually you can't read this partition from a standard (windows) system

??? Didn't know you could convince Windoze to access BTRFS!

Whatever, LZ4 is causing problems as almost all Linux systems don't include support for it on BTRFS. The result is always the same, an attempt to mount such an SD card will be rejected with a message that a feature bit is set in the file system that's not supported and you'll end up with a file system that can be read/written excusively by Xbian. I'm wondering why this patch had been included at all (on contrary to all other major distros). It couldn't be size, if the card is too small, well then buy a bigger one, they're not that pricey these days.

I once had the problem that for some unknown reason the BTRFS on the card I use for my Raspi got corrupted (which normally shouldn't happen at all, at least that's why we use a journalling FS). The Raspi did no longer boot from it, it got stuck in the very early boot phase with a respective error message begging for Btrfsck, not giving me a console to trigger that. Probably Btrfsck would've repaired the issue, maybe also a rollback to an older snapshot would've been required, but it should've been possible to reset the FS to a consistent state in a couple of minutes. However the Raspi has no second SD card slot so I couldn't trigger the check from another running helper xbian (couldn't find out if it would've been possible to change the card on the fly). I have a debian machine with tvheadend but it doesn't support LZ4, so I couldn't do the check there. I tried booting a couple of live distros, no success. Finally I got rather pissed with fruitless attempts of fishing around and I decided it will be quicker to simply reinstall xbian. It was in fact faster, however on a Raspi with no additional HDD attached xbian will not do any system backups and the corrupted FS including the snapshots was inaccessible. So I ended up with manualy repeating the complete configuration (which didn't raise my mood).

After making this lousy expierience and lots of cursing I additionally installed syncthing on xbian which I use for backing up all my other machines. It allows me to online sync any changed files to a backup machine which runs nightly dirvish hardlink backup, thus no more manual reconfiguring an xbian installation anymore. So you might understand that in my impression adding LZ4 to BTRFS without any other major distro supporting it is a big peeve and it is unclear to me why there was any neccessity at all to have that feature in the file system.

BR

Don

FYI: Since October 18 all images after that date does not use LZ4 as compression.

[BreadPit]

(4th Feb, 2019 09:31 PM)Nachteule Wrote:  @BreadPit

(4th Feb, 2019 06:04 AM)BreadPit Wrote:  The staging repo upgrade (all packages, not just Kodi18) solved the "menu is black when TV turned off during LiveTV playback". But several other bugs seemed to arise:

"Sync Playback to Display": if enabled, audio is broken. No sound.

2nd issue: sometimes after reboot, screen resolution and/or efresh rate change. I could only choose from very few options with 50/60 Hz only, after reboot I could then change back to 1080p / 24Hz.

All experienced within the first hour of trying. Seems quite buggy... Anyone else having similar behavior?

Could you please give us more information about your system!

Today I found a strange issue: when booting from network without sd-card installed (Pi3B+), Kodi can not detect resolution and sets it to 0x0p. Maybe you have same issue

No, I boot from SD. My system:

Which Pi? The latest RPi 3 B+
sd-card installed? Yes, 64GB SanDisk with latest Staging build
Debug Logs - don´t have them available
Infos about video(s) thad did not play correctly - HD TV Streams in Austria, but the videos actually played fine. The problem was the complete sound was gone, even the system sound in the menu. And the resolution also was changed in the menu.

[BreadPit]

Update: after disabling "Audio passthrough" and disabling "Sync Playback to display" ("Auto adjust refreh rate" is enabled), all seems to work fine, resoution & sound are working & stable. Only 2 issue are left:

- Some screen flashing in green when watching Live TV - once it got stuck and the screen remained green, while sound kept playing
- Audio goes out of sync when changing the channel directly with "arrow / page up". When going back to Channel list and tuning to channel from there, audio is in sync

Live TV is provided by IPTV SImple Addon with Fritzbox 6490 SAT>IP as backend, HW decoding with OMXplayer. Is this maybe behaviour of the IPTV Simple PVR addon? With Kodi 17.6 and TVMosaic in the backend, it worked great - so can I expect different behaviour with different backend / PVR-Addon?

[Nachteule]

(7th Feb, 2019 08:00 PM)BreadPit Wrote:  Update: after disabling "Audio passthrough" and disabling "Sync Playback to display" ("Auto adjust refreh rate" is enabled), all seems to work fine, resoution & sound are working & stable. Only 2 issue are left:

Sounds good

IMO, "Sync Playback to display" is usless and confusing users more than it helps. It's much better to define resolution white list and enable "Auto adjust refrresh rate"

Quote:- Some screen flashing in green when watching Live TV - once it got stuck and the screen remained green, while sound kept playing
- Audio goes out of sync when changing the channel directly with "arrow / page up". When going back to Channel list and tuning to channel from there, audio is in sync

Live TV is provided by IPTV SImple Addon with Fritzbox 6490 SAT>IP as backend, HW decoding with OMXplayer. Is this maybe behaviour of the IPTV Simple PVR addon? With Kodi 17.6 and TVMosaic in the backend, it worked great - so can I expect different behaviour with different backend / PVR-Addon?

I would say: Yes

IPTV SImple Addon -- Hmmm, that addon never worked reliable here. I used it about one or two years ago and never was happy with it.

Btw, it's never a good idea to change too much at the same time. If I understand you right, you upgraded Kodi and changed backend at the same time?

[Don Pedro]

(4th Feb, 2019 09:34 PM)Nachteule Wrote:  FYI: Since October 18 all images after that date does not use LZ4 as compression.

Good to know! But I guess when using a Pi that was installed with an older image that included compression and continually updating it via the normal xbian update process I will today have a system that is on current level but still does use compression. So in order to get rid of the compression I would have to do a fresh reinstall from a current image, right? Or is there a btrfs command that allows me to uncompress the FS on the fly and thereby remove compression, making it redable for other unix flavours?

[BreadPit]

(8th Feb, 2019 01:14 AM)Nachteule Wrote:  Btw, it's never a good idea to change too much at the same time. If I understand you right, you upgraded Kodi and changed backend at the same time?

No, the other install was a completely different Windows PC. With the raspberry, it was always IPTVsimple backend, before and after upgrade. But no long term experience, have the raspi only for a few days now, first experience.

What do you suggest as best TV backend? My experience and feeling say Tvheadend or Tvmosaic?

[Nachteule]

(8th Feb, 2019 07:20 PM)Don Pedro Wrote:  Good to know! But I guess when using a Pi that was installed with an older image that included compression and continually updating it via the normal xbian update process I will today have a system that is on current level but still does use compression.

That's correct

Quote:So in order to get rid of the compression I would have to do a fresh reinstall from a current image, right? Or is there a btrfs command that allows me to uncompress the FS on the fly and thereby remove compression, making it redable for other unix flavours?

Choice 1)
Doing a fresh install is one of the choices you have. btrfs does not have such a command, that's the bad news. But the good news is, since beginning of the year, I have added a command that allows you to recompress fs completely:

Choice 2)
You just have to run

sudo xbian-compress

That command does
1) check if btrfs is in good healh (btrfs srcub does not return an error)
2) modifying the mount option compress=lz4 to compress=lzo (compress mode can be overwritten by option)
3) check if enough space is available (> 50% free space must remain on fs) AFTER removing all unneeded snapshots
4) copying all subvolumes into new ones

After finishing command and a reboot all lz4 compressed extends are gone

Choice 3)
Another option is:

1) change compress=lzo to compress=lzo in /boot/cmdline.txt manually and reboot
2) Making an image backup (sudo xbian-config command 6 xbian copier)
3) flash this image to (new) sd card and boot from that card

[Nachteule]

(8th Feb, 2019 08:48 PM)BreadPit Wrote:  

(8th Feb, 2019 01:14 AM)Nachteule Wrote:  Btw, it's never a good idea to change too much at the same time. If I understand you right, you upgraded Kodi and changed backend at the same time?

No, the other install was a completely different Windows PC. With the raspberry, it was always IPTVsimple backend, before and after upgrade. But no long term experience, have the raspi only for a few days now, first experience.

What do you suggest as best TV backend? My experience and feeling say Tvheadend or Tvmosaic?

TVMosaic)
I do not know TVMosaic, so I can't say anything about that solution. AFAIK you need the Plus version if you want to run backend on different machine

TVheadend)
I'm using this without serious issues, but I know about 2 little annoying problems
1) With Kodi v18, LiveTV stutters for about 3s after starting (an issue has been already reported to github)
2) Walking through the timeshift buffer does work very well if you have a slower backend (like mine)
So I do not use TVH for LiveTV, but for recording it's great (because of supporting EIT)

VDR)
I'm using VDR for LiveTV, that is working perfectly on slow backends, and timeshift is absolutely flawlessly

[Tyout]

Hello everyone.

I'm new user of xbian. It's seems to work fiiiine!
I don't know much about it, and I don't find out how update to kodi 18.
I'm on raspberry pi3
I have enabled devel repo
Refresh Package list
But didn't find You have to enable devel repo
Refresh package list
But didn't find xbian-package-xbmc

Can someone hep me please?

[Nachteule]

(10th Feb, 2019 05:31 AM)Tyout Wrote:  Hello everyone.

I'm new user of xbian. It's seems to work fiiiine!
I don't know much about it, and I don't find out how update to kodi 18.
I'm on raspberry pi3
I have enabled devel repo

devel repo is not needed, staging is just enough

Terminal

root@kmxbilr2 ~ # LC_ALL=C apt-cache policy xbian-package-xbmc
xbian-package-xbmc:
Installed: 17.6-1511029903
Candidate: 18.0-1549357983
Version table:
18.0-1549357983 500
500 http://apt.xbian.org staging/rpi2-stretch armhf Packages
18.0-1548726528 500
500 http://apt.xbian.org staging/rpi2-stretch armhf Packages
18.0~RC5-1548144182 500
500 http://apt.xbian.org staging/rpi2-stretch armhf Packages
18.0~RC4-1545885938 500
500 http://apt.xbian.org staging/rpi2-stretch armhf Packages
18.0~RC3-1544307078 500
500 http://apt.xbian.org staging/rpi2-stretch armhf Packages
17.6-1511083250 500
500 http://apt.xbian.org stable/rpi2-stretch armhf Packages
*** 17.6-1511029903 100
100 /var/lib/dpkg/status
17.5-1509063284 500
500 http://apt.xbian.org stable/rpi2-stretch armhf Packages
17.4-1504805281 500
500 http://apt.xbian.org stable/rpi2-stretch armhf Packages
root@kmxbilr2 ~ #

You can see, final version of v18 is in staging repository only

Quote:Refresh Package list
But didn't find You have to enable devel repo
Refresh package list
But didn't find xbian-package-xbmc

That must work