+- Forum (http://forum.xbian.org)
+-- Forum: Software (/forum-6.html)
+--- Forum: Testing & Experimental (/forum-21.html)
+--- Thread: beta2 (/thread-1312.html)
RE: beta2 - anonimo200 - 12th Sep, 2013 12:15 AM
@mk1
Code:
XBian never ever set over_voltage by installing public IMG file, nor with performing update, nor with any other automated workflow.
Maybe you weren't in the team. It was before the attack to your old web, before the dispute with Sam Nazarko. Ask Koenkk, he even aplogized for it.
It's a bit risky make such statements without knowledge enough ...
RE: beta2 - CurlyMo - 12th Sep, 2013 01:01 AM
@animo2000, somehow you are still using XBian and i guess not without a reason. I was also one of the "lucky" who got my warranty voided in the pre-git XBian era (and indeed before mk01 joined), but instead of whining about it i took my chance and got XBian at to point that those errors aren't made anymore. There are currently two checks built-in: 1) All development occurs openly on git, so if you are worried about something, check the XBian github for these worries (like i do) 2) Await the many public pre-testing threads. They are created for users who are willing to put effort in preventing any of those issues like back then. If they support a new release, you probably don't have to worry about anything.
So, either take that change to cooperate or stop complaining because you know you are installing a pre-test beta version.
Lastly, XBian is released under GPLv2 which clearly states:
XBian vX comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
My advice at the development team would to make proper commit messages which clearly explain what a commit does and why. You can see example of these great commit messages on the github of the RPi kernel. That way, it's easier follow the development process.
RE: beta2 - namtih - 12th Sep, 2013 01:05 AM
I'm back from the business trip and can give a short feedback:
I think the overall performance hasn't improved, but the USB speed seems slightly improved. I've watched 2 movies via USB and some clips via Video Addons and all played fine. Only thing was the strange issue that I had to do the screen calibration again for every resolution.
Only thing is that some YouTube videos didn't play as smoothless as usual. Perhaps YouTube had some issues. But I think I've read that the new XBMC version has a new buffer method implemented and a new available setting for the advancedsettings.xml. Is this new method implemented? Do we need to set another value in the advancedsettings.xml?
Are those new mounts necessary, which are created with every boot?
Terminal
/dev/sda1 34 16 19 47% /media/8B12-9112
/dev/sda2 7357 1279 5592 19% /media/xbian-root-btrfs
/dev/sda2 7357 1279 5592 19% /xbmc-backup
/dev/sda2 7357 1279 5592 19% /media/xbian-root-btrfs
/dev/sda2 7357 1279 5592 19% /xbmc-backup
RE: beta2 - mk01 - 12th Sep, 2013 02:06 AM
@namtih
there was a small discussion about Yo (for example since many weeks I wasn't able to use it at all - or I wasn't patient enough). for me the clear and working solution was to rollback Yo add-on down to 4.4.4 version (from actual 4.4.6) - and was confirmed by others.
/media mounts are auto mounts by usbmount - triggered by udev reporting new block device. With mounting the device, the mount folder is also auto added to smb mounts (RO). You can set those functions (until final beta2 is released) by editing /etc/usbmount/usbmount.conf. You can also completely disable it by changing ENABLE=1 to ENABLE=0. Until beta2 is released, this control will be added to xbian-config (shell/xbmc) ((hopefully)).
/xbmc-backup should also have been explained before. It is part of automatic and easy backup/restore process of /home (so preserving Libraries/XBMC settings/etc). It creates an .img file which you can over smb/scp(sftp) drag&drop to you desktop. In case of reflash you just drag&drop it back and in few moments when XBMC reloads, you have your setup back. Quick how-to is also displayed when you trigger this function in xbian-config.
It is restore-home service, if you don't want it, disable it in xbian-config. If it's not there, just add new service yourself but I will correct this in closest commit.
@Curly
commits to git will be resumed with final commits to the state of public beta2. I freezed the code base already week/two ago now and only fixing and tuning is performed.
RE: beta2 - IriDium - 12th Sep, 2013 02:16 AM
(11th Sep, 2013 04:53 AM)f1vefour Wrote: A television generally puts out 500 milliamp, the Pi needs 1Amp.
You can't tell. The standards for USB is that it should supply 500ma but the RPi is not following that convention and only gives 100ma on each of the USB ports. Couple that with the Ethernet (Which is just another USB port) and you have another 100ma.
Typically the RPi will draw 700ma on startup (The higher the OC the higher the value) (Yes it can run on less (I've done it) - but that is not optimal) add that to 3 x 100ma (if maxed) peripherals and we have the magic 1amp PSU.
The model A obviously needs less amperage.
Which is why, WIFI dongles, USB powered HDD and other resource hungry peripherals should always use a powered Hub.
A typical flash drive will draw between 50 and 70ma so will be fine in the RPi slot.
So IMHO give the RPi as much power as you can. (Don't get technical about power being a watt
)It's just my observations
RE: beta2 - mk01 - 12th Sep, 2013 02:45 AM
(12th Sep, 2013 02:16 AM)IriDium Wrote: Typically the RPi will draw 700ma on startup (The higher the OC the higher the value) (Yes it can run on less (I've done it) - but that is not optimal) add that to 3 x 100ma (if maxed) peripherals and we have the magic 1amp PSU.
if you are with booted beta2, go to console
Code:
sudo -i
mount /sys/kernel/debug
cd /sys/kernel/debug/usb
cat devicesRE: beta2 - IriDium - 12th Sep, 2013 02:57 AM
@CurlyMo - Well said. I don't beer, whiskey or ver-mouth.
RE: beta2 - namtih - 12th Sep, 2013 03:02 AM
(12th Sep, 2013 02:06 AM)mk01 Wrote: there was a small discussion about Yo (for example since many weeks I wasn't able to use it at all - or I wasn't patient enough). for me the clear and working solution was to rollback Yo add-on down to 4.4.4 version (from actual 4.4.6) - and was confirmed by others.
I was talking about this new Gotham feature:
http://wiki.xbmc.org/?title=advancedsettings.xml#.3Cnetwork.3E
Is it already implemented in xbian? Did someone already test it (Where is Rikardo, our XBMC specialist, by the way?)
(12th Sep, 2013 02:06 AM)mk01 Wrote: /media mounts are auto mounts by usbmount - triggered by udev reporting new block device. With mounting the device, the mount folder is also auto added to smb mounts (RO). You can set those functions (until final beta2 is released) by editing /etc/usbmount/usbmount.conf. You can also completely disable it by changing ENABLE=1 to ENABLE=0. Until beta2 is released, this control will be added to xbian-config (shell/xbmc) ((hopefully)).
The problem is, that it's already disabled. So that's why I'm a little but confused why it's still there and mounted.
Terminal
root@xbian ~ # more /etc/usbmount/usbmount.conf | grep ENABLE
ENABLED=0
ENABLED=0
RE: beta2 - IriDium - 12th Sep, 2013 03:05 AM
@namtih
My mounts look like this
Terminal
/dev/sda1 7.2G 1.8G 4.8G 27% /home
/dev/sda1 7.2G 1.8G 4.8G 27% /lib/modules
/dev/sda1 7.2G 1.8G 4.8G 27% /xbmc-backup
/dev/sda1 7.2G 1.8G 4.8G 27% /lib/modules
/dev/sda1 7.2G 1.8G 4.8G 27% /xbmc-backup
Are you sure you are on the latest release?
RE: beta2 - mk01 - 12th Sep, 2013 03:25 AM
(12th Sep, 2013 03:02 AM)namtih Wrote: 1) I was talking about this new Gotham feature:
http://wiki.xbmc.org/?title=advancedsettings.xml#.3Cnetwork.3E
2) Is it already implemented in xbian? Did someone already test it (Where is Rikardo, our XBMC specialist, by the way?)
3) The problem is, that it's already disabled. So that's why I'm a little but confused why it's still there and mounted.
Terminalroot@xbian ~ # more /etc/usbmount/usbmount.conf | grep ENABLE
ENABLED=0
I just remembered the Yo issues with the code changes in 4.4.4 -> 4.4.6 so answered this separately - the symptoms were exactly like buffering issues but had nothing to do with it.
The super ultra new buffering function is under development for 1 year maybe? Intelligent processes are indeed popular, but sometimes less is better.
Whether it is implemented, ask Koen. RPI version of XBMC is not following the standard cycles as the core was behind, but clever people making progress faster than all believed so many functions are back ported to any / all existing streams and for me it is not easily readable, so I'm not following.
And buffering in general (if not very very bad network) has reasons most of the time on other places - system overloaded - bad settings - bad programming (google add-on) etc.
3) You can double check usbmount with these steps:
Code:
umount /media/8B12-9112
umount /media/usbmount-root-btrfs
rmdir /media/*
DEVNAME=/dev/sda1 usbmount add
DEVNAME=/dev/sda2 usbmount addand check mounts again. anyhow usbmount uses folder names with UUID. I would bet your xbmc is doing that. can be that you allowed it to mount through policy-kit ?
on standard xbian install, xbmc has right to umount, but not mount.
RE: beta2 - IriDium - 12th Sep, 2013 03:52 AM
Curious about all this rubbish about overclocking and initial-turbo, I had a look around - as one does. The current setting is initial_turbo=1 which if I read correctly RPiConfig means that on boot, it will only "TURBO" for one second. Is that enough? I would have thought that for boot, a vale of at least 30s should be set.
Or have I missed something here?
RE: beta2 - mk01 - 12th Sep, 2013 04:06 AM
ash again initial turbo.
yes, that is documentation from year 1996. with firmwares more recent (at the time I was adding it), any other value than =1 caused black screen without cursor, with blinking red led.
then I found somewhere =1 means 30s and finished. so it's 30 or nothing.
all-though this is reported at 2.3s
[ 2.592244] bcm2835-cpufreq: min=700000 max=930000 cur=700000
but according the xor calculation it's not 700000, but xor is evaluated at 0.3s . who really wants to know will decode the firmware.
RE: beta2 - IriDium - 12th Sep, 2013 04:15 AM
@mk01 I knew you were on the ball. Just wanted to point it out.
Re: beta2 - f1vefour - 12th Sep, 2013 09:47 AM
@mk01
I'm getting this after the last update along with high xbmc cpu usage (there are many more of the same lines):
Code:
[ 2984.082039] init: xbian-xbmc-bridge main process ended, respawning
[ 3117.362013] init: xbian-xbmc-bridge main process (21953) terminated with status 1
[ 3117.362362] init: xbian-xbmc-bridge main process ended, respawning
[ 3250.528121] init: xbian-xbmc-bridge main process (22840) terminated with status 1(12th Sep, 2013 02:16 AM)IriDium Wrote:(11th Sep, 2013 04:53 AM)f1vefour Wrote: A television generally puts out 500 milliamp, the Pi needs 1Amp.
You can't tell. The standards for USB is that it should supply 500ma but the RPi is not following that convention and only gives 100ma on each of the USB ports. Couple that with the Ethernet (Which is just another USB port) and you have another 100ma.
So IMHO give the RPi as much power as you can. (Don't get technical about power being a watt
It's just my observations
What are you saying, what I was saying is dont power the Pi with the TV USB port. Nothing about the Pi USB power output capability.
It amp not watts.
RE: beta2 - ilgrank - 12th Sep, 2013 06:35 PM
Quote:What are you saying, what I was saying is dont power the Pi with the TV USB port. Nothing about the Pi USB power output capability.
YMMV, but I'm powering my Pi from my TV usb port (sharp aquos).
The Pi is overclocked to 900MHz (but not overvolted) and it is running rock stable.
I've measured power output of my tv set usb port up to 1040mAh: I know it is out of specs, but many tv vendors do provide 'overpowered' usb ports to have their users run external hdds with no issues.
As a general rule tho, use a short usb cable (mine is 10cm) and you'll have less power loss (less voltage drop due to cable length) : your Pi will run fine from the TV USB port.