[badmonkey]

(3rd Dec, 2013 09:12 PM)mk01 Wrote:  

(3rd Dec, 2013 08:59 PM)badmonkey Wrote:  ok - this appears to be the daily cron running a task to create a btrfs snapshot - is there any way to suppress alerts for that action ?

apart from that I only notice a couple of very minor nit-picks :-

1) The time syncs after xbmc has loaded (maybe about 15 seconds after the gui appears, but during my scan for new media)
2) Audio starts playing about a second before the video appears - everything is in sync, you just don't see the first second of video.

@Paul

2 - if you are syncing (hz) to video (fps) this is due the TV changing resolution. you can set "pause video for xy ms" during video screen resolution change.

1 - there are few solutions - depending on your usage pattern.
- XBian restores 'fake' clock (time saved during shutdown/reboot) early in the boot. if you don't turn your RPI off, this 'wrong time will be max 1m behind the real
- If you ARE turning RPI off for days, this can be issue but - I use setting where Date added to the library is time of file creation on local filesystem, not time at Library update. So it would become irrelevant again. Last option is to wait with XBMC - ugly - without network XBMC won't start. By what add-on/app are you updating the lib? or just you checked update upon start ?

---

@Paul

we are aware that accessing sub-volumes for what ever reason is triggering this info window. Unfortunately we have no simple solution until now - if I don't consider hard patching of XBMC code. so somehow this is still under consideration - waiting for external know how

last resort is patching which I'm a bit against. much work and commitment for updates for little benefit. let's see.

Thanks for the info - I didn't think about looking through video settings within xbmc - I'll have a play with those.

I'm just updating library on boot with the standard option, no extra addons - everything seems to work fine though, it's just different to pre beta 2 where the time was right on boot.

The btrfs message is no problem - I thought it was just me at first until I had a look at the daily cron jobs.

Cheers

Paul

[mk01]

(3rd Dec, 2013 08:09 PM)Smultie Wrote:  I guess I was one on the persons complaining about really slow apt-get in beta 1.1
Haven't experienced it (yet) in Beta2 but before it looked like it got slower over time.

Yes, sorry Smultie - specially not reminding you

in general this 'fact' will stay - as we still use btrfs - which is b-tree COW filesystem - and using APT-GET and having SNAPSHOTS. one would call it killer combo.

as:
1) COW will re-write ALL data or METADATA for single smallest file change
2) APT_GET by design unpacks a copy for all existing package files, then creates links and then don't know. already there it is terrible
3) each snapshot means metadata record of single data stored somewhere, during update in any snapshot, all related records across snapshots gets updated with new info (not data, but metadata is enough) and if filesystem is mounted with atime or even relatime (accessing file means it's metadata change which will cause update / recheck across snapshots which will cause .... it's like never ending techno party)

We did our best to help as much as possible, at least we tried. FS is remounted with noatime after boot. FS doesn't contain DOUBLE metadata structure for SSD/SD drives. Metadata blocks are larger (4x) to generate less IO and LIMIT the problematic metadata fragmentation.

I had no more ideas in this area. Definitely not easy fight with old simple filesystems like extX. But they are scary.

---

(3rd Dec, 2013 09:30 PM)badmonkey Wrote:  I'm just updating library on boot with the standard option, no extra addons - everything seems to work fine though, it's just different to pre beta 2 where the time was right on boot.

you can consider the date added meaning switch. it has one big advantage though - if you lose your lib an d decide to rescrap, the old way will change the order in recently added. totally. if you change date added to mean file creation time, this will stay constant. do the best for you.

as for different behavior. there is not much to do, ntod will not sync quicker than 40-50s,. but beta2 is attaching network faster, xbmc is starting sooner and faster.

for time being you can add "started ntp" ti other start on stanzas in /etc/init/xbmc.conf. during next days we can implement this as user configurable option (ti wait fir REAL time ti be acquired). this can take hours in case time diff is big (RFC documents).

other option could be use ntpdate instead of ntpd 0 ntpdate is not following the rules and is doing big time jumps without hesitate.

let's thing about all this few days,.

[Tero Turtiainen]

I give up with Beta 2. Earlier I reported my problems with the Beta 2 image. The "best" I could get is XBian booting to XBMC (and wow, it seemed much faster than Alpha 5!) but the root partition being read only.

Now I tried upgrading from Alpha 5 to Beta 2. Everything seemed to go fine but after the reboot at the end of the upgrade I got once again that recovery console.

Maybe both of my RasPies are broken but I'll go back to Alpha 5 .At least it works.

[IriDium]

@Tero Turtiainen Have you tried just installing a new version of Beta 2 without the upgrade? Do you have the same problems?

[Tero Turtiainen]

(4th Dec, 2013 05:48 AM)IriDium Wrote:  @Tero Turtiainen Have you tried just installing a new version of Beta 2 without the upgrade? Do you have the same problems?

Yes, I have tried both upgrading from Alpha 5 and downloading and writing the image. With two Pies and three SD cards. Maybe I am very unlucky and all of those are broken :-o But somehow Alpha 5 seemed to run fine.

Well, I guess I could still try "underclocking". Didn't default XBian configs use higher than default CPU frequency?

[Tero Turtiainen]

Ok... Now I tried the default CPU frequency settings and whoa! It booted. Read-write filesystem! Everything seemed to be working. Then I did apt-get upgrade and about a dozen packages were updated. The system rebooted and... then nothing happened. Only red led is turned on, the green does not blink, nothing is shown on the TV.

I think I have a case of SD card corruption with both my Pis and all my SD cards. I think I'll try moving the file system to USB drive or something. So I did not give up yet

[freem@n]

You seem to be very unlucky, man. My Pi is clocked even higher than default XBian clock and is running directly from the SD card...never had any corruption so far.

[sam397]

(1st Dec, 2013 12:54 AM)IriDium Wrote:  Xbian really does need a network connection - especially for the time.

By not having a system clock files will be written with a 1970 date which will confuse sort programs or thers which rely on timestamps.

Does this mean that running xbian without a network connection is not supported?

(1st Dec, 2013 12:54 AM)IriDium Wrote:  I have a feeling this "issue" is caused by ntp failing which triggers Xbmc to stop - or something like this.
Can you go into xbian-config and set the service ntp to stop and not restart. Reboot and see if that improves things.

I disabled autostart of service 'ntp' and rebooted. No luck. Again i get "starting xbmc..." for over a minute during start, then "xbian login:", the finaly xbmc starts. In xbian-config service 'ntp' now has status 'stopped'.

(1st Dec, 2013 08:54 AM)mk01 Wrote:  by any chance is your eth0 IP setting static?
can you test fix for similar situation contained in xbian-update version 1.0.2-10 or higher currently available on devel repo?

xbian-config -> System -> Network:
Interface eth0
Status DOWN
Mode DHCP

I will test the package and give you feedback.

[mk01]

sam397,

normally no network connection doesn't matter as standard devices have RTC. but RPI does not. RPI without internet (or local ntp server) will always start at 1/1/1970.

you CAN"T imagine how terrible things can happen due a simple fact nobody (app programmer, system programmer) is expecting - numbers going backwards. or small break (1s) which will never occur.

just wan't to say, system as software will work of course but sqlite db, maintenance on it and possible other could have undesired endings. if you need to use RPI without network (or ntp server accessible), buy a RTC. for instance http://www.adafruit.com/products/264

there is no dependency to ntp currently to xbmc stopped/starting/started ntp should have no impact to xbmc startup. but will recheck.
what is happening there is maybe no-network + eth0 marked auto -> time out and failsafe condition . killing xbmc on request.

remove auto eth0 from /etc/network/interfaces an d check if now is starting without crash / restart / lags.

[cd1]

Hello All,

I am trying to get xbian beta 2 working on raspberry pi. I make the SD card and boot up with it and everything goes well and it goes thru the manager screen in the startup. The thing is that I don't get an DHCP address.. However the network cable is plugged in and working. The way I confirmed this is that I installed xbian beta 1.1 and it works fine. The only issue in this release is that the power off system brings the system down and then powers it on again. not sure why.. Can anyone fill me in on this.

thanks

[rikardo1979]

(6th Dec, 2013 02:58 AM)cd1 Wrote:  Hello All,

I am trying to get xbian beta 2 working on raspberry pi. I make the SD card and boot up with it and everything goes well and it goes thru the manager screen in the startup. The thing is that I don't get an DHCP address.. However the network cable is plugged in and working. The way I confirmed this is that I installed xbian beta 1.1 and it works fine. The only issue in this release is that the power off system brings the system down and then powers it on again. not sure why.. Can anyone fill me in on this.

thanks

merged your thread into this as there is no need to have a separate one for Beta2 related stuff

[Skywatch]

Hi,

After upgrading to 1b2 I have a problem.

I can no longer SSH into the pi. Also the network workgroup has been changed to 'WORKGROUP' which is not what I used before the upgrade.

I can't seem to change this within XBMC Xbian meny and as I can no longer SSH in I am stuck.

Any sugestions please?

Thanks

Skywatch

[rikardo1979]

(6th Dec, 2013 04:22 AM)Skywatch Wrote:  Hi,

After upgrading to 1b2 I have a problem.

I can no longer SSH into the pi. Also the network workgroup has been changed to 'WORKGROUP' which is not what I used before the upgrade.

I can't seem to change this within XBMC Xbian meny and as I can no longer SSH in I am stuck.

Any sugestions please?

Thanks

Skywatch

!!! Please, can you stop opening new threads for Beta2 ? !!!

[Skywatch]

OK then, I give up!

[mk01]

(6th Dec, 2013 04:22 AM)Skywatch Wrote:  I can't seem to change this within XBMC Xbian meny and as I can no longer SSH in I am stuck.

skywatch. if it ids only that than what about XBMC quit ? you have direct console then.