Forum

Device detected but not mounted. It works on Beta 1.1 but not Beta 1.2.

8g Flash Drive:
Detected in dmesg http://pastebin.com/LWmkq6kd
lsusb: Bus 001 Device 008: ID 8564:1000
lsusb -v -s 1:8 http://pastebin.com/f0ENXVJg

But has not been mounted so can't be seen.

Same if direct in RPi or via a hub. Drive is recognised in OSX and Windoze

Server http://ivka57.dyndns-ip.com is down at the moment and has been for a couple of days.

(7th Aug, 2013 07:24 PM)IriDium Wrote: [ -> ]Device detected but not mounted. It works on Beta 1.1 but not Beta 1.2.

8g Flash Drive:
Detected in dmesg http://pastebin.com/LWmkq6kd
lsusb: Bus 001 Device 008: ID 8564:1000
lsusb -v -s 1:8 http://pastebin.com/f0ENXVJg

But has not been mounted so can't be seen.

Same if direct in RPi or via a hub. Drive is recognised in OSX and Windoze

Can you manually mount the drive?

Strange! I used the Flash Drive to install BETA 1.1 on it - and it now appears as mounted. Previously it would have been FAT32, whereas now it's btrfs.

If I plug my Android phone in - and turn on usb storage it attempts to connect but fails. The same on Beta 1.1

Another Problem:
-------------------------------------

There seems to be a btrfs "checking program" running. BTRFS debug (device mmcblk0p2): unlinked 5 orphans. However, when it runs, it unmounts the drive (visible in xbmc) and then remounts it. This "pops up" the new browse function within xbmc on xbian-root-btrfs.

dmesg:
device label xbian-root-btrfs devid 1 transid 1017 /dev/mmcblk0p2
BTRFS debug (device mmcblk0p2): unlinked 4 orphans

This could get annoying when watching a movie!

(8th Aug, 2013 06:39 PM)IriDium Wrote: [ -> ]Strange! I used the Flash Drive to install BETA 1.1 on it - and it now appears as mounted. Previously it would have been FAT32, whereas now it's btrfs.

If I plug my Android phone in - and turn on usb storage it attempts to connect but fails. The same on Beta 1.1

Another Problem:
-------------------------------------

There seems to be a btrfs "checking program" running. BTRFS debug (device mmcblk0p2): unlinked 5 orphans. However, when it runs, it unmounts the drive (visible in xbmc) and then remounts it. This "pops up" the new browse function within xbmc on xbian-root-btrfs.

dmesg:
device label xbian-root-btrfs devid 1 transid 1017 /dev/mmcblk0p2
BTRFS debug (device mmcblk0p2): unlinked 4 orphans

This could get annoying when watching a movie!

I'm aware of it, unfortunately I don't have a solution yet. It's the same as with /boot (auto mount / umount).

but reason for that is btrfs-auto-snapshot run. it mounts the fs with subvol=/ to have access to all volumes. this triggers the popup in xbmc and on amount it triggers the unlinking of orphans.

I don't know which revision you have (/etc/xbian_revision) but already since 13 or 14 there is no schedule to run snapshoting hourly, just daily and weekly and anacron is running those jobs between 05-07am. so should not distract from movie

I was already asking for help about configuring this auto-popup feature of xbmc, but nobody replied. so I'm slowly reviewing xbmc sources and seems that there is no config / variable to dynamically set criteria for popups. And I'm not really keen into patching xbmc code. It would be as solution, but …

Going to your first topic, I don't get it fully what you mean. You installed xbian onto flash drive. Ok. But it's clear it will be btrfs.

---

@f1v4

you are using lirc if I remember correctly? can you update lirc package to 1.4-6 ? it has upstart script. functionality should be as with 1.4-5 (right module should be in /etc/modules, lirc starting trying auto detect the loaded module and choose right config / binary to start).

and is started before xbmc.

---

(7th Aug, 2013 07:24 PM)IriDium Wrote: [ -> ]lsusb: Bus 001 Device 008: ID 8564:1000
lsusb -v -s 1:8 http://pastebin.com/f0ENXVJg

kernel config is the same for 1.1 and 1.2, only kernel ver different 3.9 vs 3.10

rpi can't recognize partitions on the disk, this mostly leads to non loaded usb_storage module. can you check, that usb_storage is loaded ?

---

(6th Aug, 2013 09:34 PM)IriDium Wrote: [ -> ]Just happened again. Only thing I could gleam from dmesg was:
init: xbian-xbmc-bridge main process (1513) terminated with status 1
init: xbian-xbmc-bridge main process ended, respawning

this looks like xbmc process crashed (even if still on the screen).

which kernel you have? on 3.10.3+ someone wrongly merged patches and usb stack was quite messed up with lots of oops points. with 3.10.4+ now it looks ok - although I had no such freezes, but I start from SD and watch through NFS. but still I noticed lots of oops debug messages in dmesg console.

---

(6th Aug, 2013 04:02 AM)IriDium Wrote: [ -> ]IMHO: Beta2 seems so reliable, it should be released to a select few for further testing - especially in the areas of Navi-x (and derivatives), Airplay, Mice and remotes, and playback over network.

what needs to be solved are the lirc and keymap issues. As I'm full CEC with no IR devices (i have few Apple remotes, but no IR receiver for RPI) - this is area I have not beed focused to.

I also have centralized media library and all media files on network and no windows in house, just linux and Macs. from this:

1) lirc - just now I rewritten the scripts to upstart with starting before xbmc. so we need to pinpoint if the recent issues with beta 1.1 has something todo with the recent Koenns code updates, or the whole problem was bug in beta1 which removed all modules from /etc/modules and the fact, that lirc was starting from runlevel2 which is starting AFTER xbmc was started - some leads are now and then infos, that stopping and starting xbmc helps to get lirc support or the fact, that without lirc module loaded BEFORE lircd is starting, all config files used are not the proper one.
2) CIFS - connect to samba shares. I'm using nfs and nfs4, this is properly tested, but not CIFS
3) Video and Music library on local drive, with at least 500+ movies, at least 5000+ songs. If xbmc on RPI and CoW filesystem is somehow still acceptable solution (memory usage, speed)

now and then I use Airplay as well, but Yamaha recently integrated AirPlay into their RX AV product line so I changed two receivers - RPI was working, but delay is long and buffer short. But if any problem should be found, it's again some combination of avahi-daemon and dbus.

---

(6th Aug, 2013 01:51 AM)IriDium Wrote: [ -> ]Nothing in any of those folders. It must be mounted somewhere as it can read the unique DVD ID but within XBMC it "seems' to be mounted on / because of the folders I can see.

May be related to http://forum.xbian.org/thread-1186.html?highlight=dvd

Right clicking shows Play Disc, Eject/Load but none of them work.

I will try if I find the ext USB DVD drive, but this looks like XBMC relies on it's internal compiled support rather than system wise.

kernel scsi sg (cdrom) support is compiled, you can try loading "sg" module. but again, never tried before.

(6th Aug, 2013 04:02 AM)IriDium Wrote: [ -> ]@mk01 Can Beta 2 be installed onto a USB drive and if so how? I would like eventually for it to be included into xbian-config (along with a restore function) but I know that is not your area.

I don't know about the installer (we should ask Koenn), but as with the system (or image), it doesn't really depends. so if you use dd, you can put the image on any media. the only stopper is RPI's boot workflow, which needs firmware and kernel on internal SD card, on first partition which must be FAT.

So even if we put option into installed to restore on any media, user would be NEEDED still to take SD card and manage the /boot stuff. maybe it can be option like: put image on usb stick / drive with checkbox "I will provide SD card as well to prepare the /boot". so after ing restore, user would asked to connect sd card and installer would prepare just the FAT boot partition.

the other option is to install as per today, then boot and (since beta2) start xbian-config (shell), choose copy to USB.

Updated to the latest version. Revision 00015

Noticed that NTP and XBMC attempt to start at boot but both fail. Have to be started via xbian-config. Nothing notable in dmesg.

Also a standard USB keyboard is recognised (in dmesg) but doesn't work in XBMC.

Xbian USB copier doesn't work. Error line 138 No such file or directory

(14th Aug, 2013 02:01 AM)IriDium Wrote: [ -> ]Updated to the latest version. Revision 00015

Noticed that NTP and XBMC are not started at boot.

latest is 17 dated yesterday 9pm CET. just do the usual

and if xbian-update is not upgraded, do

but be sure with "apt-get clean", otherwise xbian-update will be reinstalled from local cache. xbian-update is the only package I can't bump it's version on each run, so apt must not have noticed it's change.

(14th Aug, 2013 02:05 AM)mk01 Wrote: [ -> ]

(14th Aug, 2013 02:01 AM)IriDium Wrote: [ -> ]Updated to the latest version. Revision 00015

Noticed that NTP and XBMC are not started at boot.

latest is 17 dated yesterday 9pm CET. just do the usual

Code:

apt-get clean; apt-get update; apt-get upgrade

and if xbian-update is not upgraded, do

Code:

apt-get install —reinstall xbian-update

but be sure with "apt-get clean", otherwise xbian-update will be reinstalled from local cache. xbian-update is the only package I can't bump it's version on each run, so apt must not have noticed it's change.

I ran the upgrade from xbian-config, which might explain it.

#apt-get upgrade
Did not install any additional packages, so reinstalling xbian-update.

Ok - Now on 00017. NTP, XBMC and KB are working.
However, Network is not. dmesg shows xbian-bridge processes terminated. Could that be why?

(13th Aug, 2013 07:34 AM)mk01 Wrote: [ -> ]@f1v4

you are using lirc if I remember correctly? can you update lirc package to 1.4-6 ? it has upstart script. functionality should be as with 1.4-5 (right module should be in /etc/modules, lirc starting trying auto detect the loaded module and choose right config / binary to start).

and is started before xbmc.

Updated and once again remote is nonfunctional.

The update moved my /etc/lirc/lircd.conf to /etc/lirc/lircd.conf.xbian. I had to move it back, restart lircd then XBMC to fix.

mk01 we need an intelligent way to add the contents of the new lircd.conf to the existing one, or at least use an include.

Currently the contents of /etc/lirc/lircd.conf are


The stock file should add an include to a new place in /home/xbian/.remotes/myremote.conf so we can add our custom configuration to this file and it will always be picked up upon updates.

So first we add /home/xbian/.remotes/myremote.conf to /etc/lirc/lircd.conf making it


Then we create the directory and file:


Add necessary contents to /home/xbian/.remotes/myremote.conf which will be safe from deletion/changes from future updates.

Finally we edit the wiki on xbian remote control to reflect the new way of configuration.

(14th Aug, 2013 02:20 AM)f1vefour Wrote: [ -> ]Add necessary contents to /home/xbian/.remotes/myremote.conf which will be safe from deletion/changes from future updates.

Finally we edit the wiki on xbian remote control to reflect the new way of configuration.

what about this:

I will remove Koenn's code responsible for overwriting .conf files.

I will put .conf files under conffiles dpkg directive (normally dpkg asks about such files (if changed by user locally) if should be overwritten from .deb - xbian's dpkg setting overwrites this and tells dpkg to never overwrite config files.

Scripts will stay as they are. So if changed, will be replaced with new from .deb.

are you ok with that ?

mk

(14th Aug, 2013 02:57 AM)mk01 Wrote: [ -> ]

(14th Aug, 2013 02:20 AM)f1vefour Wrote: [ -> ]Add necessary contents to /home/xbian/.remotes/myremote.conf which will be safe from deletion/changes from future updates.

Finally we edit the wiki on xbian remote control to reflect the new way of configuration.

what about this:

I will remove Koenn's code responsible for overwriting .conf files.

I will put .conf files under conffiles dpkg directive (normally dpkg asks about such files (if changed by user locally) if should be overwritten from .deb - xbian's dpkg setting overwrites this and tells dpkg to never overwrite config files.

Scripts will stay as they are. So if changed, will be replaced with new from .deb.

are you ok with that ?

mk

That would work but I think my way is more ideal because a user can create his own configuration in /home without the messiness of adding a big remote configuration to a system level file (/etc/lirc/lircd.conf).

The way I described is more proper and if course I tested it and verified it works by adding the include.

Also most people don't know if they should allow the package maintainers version to overwrite their version, this causes confusion.

I personally prefer my way but since your the developer you should choose.

this config files "games" have it not considered before, more question was going more to direction of starting stopping, as I removed the old sysv script and created new upstart.

this part is ok ?

(14th Aug, 2013 03:07 AM)mk01 Wrote: [ -> ]this config files "games" have it not considered before, more question was going more to direction of starting stopping, as I removed the old sysv script and created new upstart.

this part is ok ?

It is working great, lircd upstart is good.

(14th Aug, 2013 03:06 AM)f1vefour Wrote: [ -> ]That would work but I think my way is more ideal because a user can create his own configuration in /home without the messiness of adding a big remote configuration to a system level file (/etc/lirc/lircd.conf).

The way I described is more proper and if course I tested it and verified it works by adding the include.

Also most people don't know if they should allow the package maintainers version to overwrite their version, this causes confusion.

I personally prefer my way but since your the developer you should choose.

you can stay with you config, it doesn't matter.
whole /etc is there for modification by user. it is purpose of it. config files should never be overwritten by maintainer and this is clearly stated. there are deb helper tools to help maintainer with updating conf structure to a new version while keeping users configuration. packages which does not follow this rule are never put into distribution. if really high demand, then they go to extra section of repo, but never main.

simply that's the wrong way.

lirc was even hiding scripts under .conf files, stored under /etc …

your approach is commonly used for multiuser systems (ssh key storage, bash rc / profile etc) …

if you have 20 minutes, please upgrade lirc to 1.4-7. conf files should be kept, just for sure do a copy of /etc/lirc before.