Trouble swapping Bluray and DVD discs

Help and Support Raspberry Pi
1

I have been watching shows straight from retail discs lately using a USB Blu-Ray drive and find that udisks seems to have trouble more often then not when I put a new disc in. Occasionally it just works and everything mounts correctly.

But usually the play disc and eject buttons (Aeon Nox skin) which only show up when a disc is inserted do show but nothing plays because nothing is actually mounted. I find when this happens I can’t even use the eject button on screen. Also SSH’ing in and running “eject -T” gives a I/O error.

The only two fixes I found is a reboot, or I can manually mount the drive with “sudo mount /dev/sr0 /mnt” which then it works and I can watch the show. When I umount it it even ejects it then “eject -T” starts working again to close the drive.

Here is some output from journalctl of me swapping a retail Bluray disc and not having the next one work correctly. You will notice it does know the disc is in and even reads the right volume label.

Sep 08 17:00:27 mainmc udisks-glue[30094]: Device file /dev/sr0 unmounted from /media/HEROES_S1_D4_NA
Sep 08 17:00:32 mainmc udisks-glue[30094]: Device file /dev/sr0 removed
Sep 08 17:01:14 mainmc udisks-glue[30094]: Device file /dev/sr0 inserted
Sep 08 17:01:14 mainmc udisks-glue[30094]: Trying to automount /dev/sr0…
Sep 08 17:01:14 mainmc udisks-glue[30094]: Failed to automount /dev/sr0: Error mounting: mount: /dev/sr0 is already mounted or /media/HEROES_S1D5 busy

This is a Raspberry Pi 2 with a external LG Bluray drive. I haven’t included any Kodi debug log since this is a OS problem with mounting not a Kodi watching problem since libaacs is working fine for decrypting as soon as it does mount.

2

Probably the same issue reported here, and here.

Something has changed (probably in the kernel) that has subtly broken udisks detection of disks. (Nothing was changed in our udisks configuration in the time between when it was working properly and when users started to report this problem)

Still trying to figure out the exact cause, which is not helped by the fact that I cannot reproduce the problem at all on my own hardware. (Auto mounting works 100% for all the drives I’ve tried on my Pi 2)

By the way a full log is helpful when trying to diagnose these problems - log snippets don’t really help because you don’t know what we’re looking for when we’re trying to diagnose the problem.

So please try to reproduce the problem then upload the full journal with:

sudo journalctl | paste-log
3

Can you try upgrading your installation and seeing if the issuer persists?

Sam

4

I just updated which was just the diskmount-osmc package and it didn’t fix it.

Fresh boot, just opened and closed the drive and it didn’t work.
http://pastebin.com/xq9SkuM9

5

How is your DVD drive powered ?

You’ll need to explain what you did when this log was taken - at 13:50:45 it says the drive was successfully mounted, but then at 13:51:10 it is shown as being unmounted, then attempting to mount again at 13:51:52 - did you try to eject the disk then re-insert it ?

Search for udisks-glue in your log and you will see the lines showing it is mounting and unmounting the disk…

In my experience, if a DVD disk mounts such that you can browse to the files/folders on the disk, (or such that the mount point in /media appears but contents are empty) but does not bring up the Disc menu that lets you play a DVD movie, it is due to read errors on the disk, or IO timeouts due to disk errors and multiple retries when reading. You also say that eject gives an I/O error, this is also a sign that the drive is having trouble reading the disk.

Have you tried different disks to see if all are equally affected, and more importantly have you tried a different DVD drive ? In testing I did with an old USB DVD drive at work I had intermittent symptoms very much like you describe but it turned out to be the drive itself that was faulty and having difficulty reading the disks…

6

The drive is self powered.
I specified in my post that I did a fresh boot then recreated the problem by opening and closing the drive
It happens equally on many discs (I just recently finished watching a whole 10 seasons of Stargate on DVD with it happening with most discs then the whole first season of Heroes on Blu-Ray with same results)

The drive works perfect and has for years on my Linux systems.

7

If by self powered you mean it is getting it’s power from your Pi then there may be insufficient power to run it reliably.

What sort of power adaptor are you powering the Pi with ? Are you using max_usb_current=1 in config.txt ?

Can you try powering the USB drive some other way, for example via a powered USB hub ?

8

No it powers itself with its own power cord.

Also my Pis power cord is great 5v 3a fixed cable for less loss. The lowest I saw it when testing with a multimeter is 4.95v and that was watching a full Blu-ray over nfs through a high power USB WiFi card will simultaneously updating my library and sshing in and using dd to image a external 2.5" drive that was completely powered by the pi and wouldn’t even power on with max usb current

9

So, backing up a bit, if you look in /media, does the disk mount in /media every time you insert it, even if Kodi doesn’t display the option to play the Disc ?

And if you check in the mounted directory, eg /media/HEROES_S2D1 do you always see the correct files listed ?

If so, the problem is not with udisks-glue mounting the disk (as if it was, it wouldn’t appear in /media at all) but either read errors reading the disk causing Kodi not to recognise it as a playable DVD, or possibly a bug in Kodi.

BTW, please don’t use the linux eject command to eject the disk - if you do so you will cause errors like the following:

Sep 09 13:51:32 mainmc udisks-glue[370]: Trying to automount /dev/sr0...
Sep 09 13:51:32 mainmc udisks-glue[370]: Failed to automount /dev/sr0: Error mounting: mount: /dev/sr0 is already mounted or /media/HEROES_S2D1 busy

The eject command will eject the disk without unmounting it properly, which will make the disk (and possibly the whole drive) unreadable until you reboot.

You should unmount the drive instead using either the eject or safely remove options in Kodi, (or umount /media/HEROES_S2D1 from the command line) which actually trigger an unmount not an eject - udisks glue then calls eject for you after the disk is safely unmounted.

We have also configured the physical eject button on DVD drives to perform an unmount if mounted and only an eject if unmounted - this is handled automatically for you, but uder some conditions you might need to press the button twice.

If you are using the eject command via ssh you are actually causing part of your problem.

10

When the problem occurs nothing shows up under /media

I only tried the eject command as a test after the fact I normally use the on screen eject option. Which does show a on screen message about it unmounting it properly. Then for closing it I just use the button on the drive after putting the new disc in.

I doubt it is read errors because the drive works fine when connected to other systems and these are new discs of which I can’t image all 50-60 being bad when I bought them new and this is only my second time watching through them.

11

Since I updated today after this commit [package] [diskmount-osmc] Wait for 'udevadm settle' to complete duri… · osmc/osmc@ad3ace8 · GitHub everything seems to be working better. I’ll keep testing to see if it’s fully fixed or just doesn’t happen as often.

12

That commit has not been pushed out to users yet, so unless you manually installed version 1.4.0 using wget and dpkg -i (as described in another thread) then I’m afraid this is only a coincidence, which is quite likely when the problem is intermittent in the first place…

13

Must of been whatever the last pushed commit for that package because I do know that when it started getting better I updated the diskmount-osmc package.

The last time was when Sam asked me to update and test which did update that package and if anything made it worse. Then a couple hours after that commit was posted I did another update which just updated diskmount-osmc again to 1.3.8 (currently installed) After that it has been noticeably better.

I always dist-upgrade from the command line and never from OSMC settings so that I can see exactly what packages are being upgraded so I can narrow down any problems that arise right after. Which is how I know that it started being better immediately after upgrading diskmount-osmc.

14

Do you happen to know which version you were on before you updated to 1.3.8 ? A number of versions were released in rapid succession, so you may have skipped a version or two.

This is the version history of the package here:

Could you try testing 1.4.0 for me ? Instructions to manually install this are in this post:

It’s possible to downgrade back to 1.3.8 if necessary.

Keep in mind that the mounting issues are of an intermittent timing related nature (race condition) which means you would need to test it many times to get an idea of whether it works properly or not.

15

Yes I do know because I checked the apt log. 1.3.3 and 1.3.6 where basically the same when I went to 1.3.7 it got worse and then 1.3.8 has worked fine. Only 1 problem (first time but I hadn’t rebooted yet then the next dozen worked perfect (spent a minute opening and closing to test).

When I wake up I’ll upgrade to 1.4.0 and sit by it for awhile opening and closing to see how it does.

Start-Date: 2015-09-07 00:09:22
Commandline: apt-get dist-upgrade
Upgrade: apt:armhf (1.0.9.8, 1.0.9.8.1), libudev1:armhf (215-17+deb8u1, 215-17+deb8u2), dbus:armhf (1.8.18-0+deb8u1, 1.8.20-0+deb8u1), systemd-sysv:armhf (215-17+deb8u1, 215-17+deb8u2), multiarch-support:armhf (2.19-18, 2.19-18+deb8u1), python-apt-common:armhf (0.9.3.11, 0.9.3.12), systemd:armhf (215-17+deb8u1, 215-17+deb8u2), libc6:armhf (2.19-18, 2.19-18+deb8u1), libsystemd0:armhf (215-17+deb8u1, 215-17+deb8u2), libc6-dev:armhf (2.19-18, 2.19-18+deb8u1), udev:armhf (215-17+deb8u1, 215-17+deb8u2), libdbus-1-3:armhf (1.8.18-0+deb8u1, 1.8.20-0+deb8u1), libapt-pkg4.12:armhf (1.0.9.8, 1.0.9.8.1), python-apt:armhf (0.9.3.11, 0.9.3.12), locales:armhf (2.19-18, 2.19-18+deb8u1), base-files:armhf (8+deb8u1, 8+deb8u2), libgnutls-deb0-28:armhf (3.3.8-6+deb8u2, 3.3.8-6+deb8u3), apt-utils:armhf (1.0.9.8, 1.0.9.8.1), libc-dev-bin:armhf (2.19-18, 2.19-18+deb8u1), libapt-inst1.5:armhf (1.0.9.8, 1.0.9.8.1), libpam-systemd:armhf (215-17+deb8u1, 215-17+deb8u2), libc-bin:armhf (2.19-18, 2.19-18+deb8u1), diskmount-osmc:armhf (1.3.3, 1.3.6), libgudev-1.0-0:armhf (215-17+deb8u1, 215-17+deb8u2)
End-Date: 2015-09-07 00:11:20

Start-Date: 2015-09-09 13:50:25
Commandline: apt-get dist-upgrade
Upgrade: diskmount-osmc:armhf (1.3.6, 1.3.7)
End-Date: 2015-09-09 13:50:29

Start-Date: 2015-09-11 14:02:44
Commandline: apt-get dist-upgrade
Upgrade: diskmount-osmc:armhf (1.3.7, 1.3.8)
End-Date: 2015-09-11 14:02:48

16

Thanks for keeping a log of the versions, that’s very helpful. I’ll study the changes in those different versions to see if I notice a correlation between the changes and the results. 1.4.0 takes a completely different approach to 1.3.8 so it will be interesting to see what result you get on your DVD drive as it is primarily hard disks failing to mount on boot that all the recent diskmount changes have been trying to fix.

17

Hmm. I don’t really see a possible cause for 1.3.7 working OK for you and 1.3.8 not. Here is a summary of changes since 1.3.3:

1.3.4: a change to udisks-glue.conf to eliminate log spam if samba was installed but disabled. (not relevant to mount problems)

1.3.5: not published due to a typo in the service

1.3.6: add After=systemd-udev-trigger.service (wait for this service before starting udisks-glue) - possibly relevant but you say you didn’t notice a change between 1.3.3 and 1.3.6 so it was probably doing nothing.

1.3.7: add After=polkitd.service and also ExecStartPre= /bin/udevadm trigger --subsystem-match=block - the latter could have major ramifications on the way devices are detected and could potentially make things worse (as you note)

1.3.8: added an extra debug line to udisks-glue.conf: /usr/bin/udisks --show-info %device_file. This line is only run to gather more information if the drive has already failed to mount correctly. I can’t see any possible way that this would fix the problem you saw in 1.3.7, which makes me think you are being tricked by an intermittent problem.

1.3.9: most of the changes to the service unit were reverted back to their original 1.3.3 state. (not published)

1.4.0: add ‘udevadm settle’ as an ExecStartPre - this should delay the startup of udisks-glue until all udev processing has finished. (not published yet)

So unfortunately I don’t see any clear correlation between most of your results and the changes that were made, leading me to believe that the intermittent nature of the problem is making it difficult to gather meaningful results.

I’ve just remembered another possible cause of a DVD not mounting at boot time that I have experienced myself - some DVD drives will present themselves as a different type of device (a bootable drive, rather than a CD/DVD rom drive) to the operating system if there is already a disk in the drive and the drive has been turned on a few seconds before the Pi boots - this would be the case during a warm reboot for example.

If you make sure to remove the disk before booting/rebooting and only insert it later do you ever get a failure for it to mount when inserted ?

18

I don’t have a problem with it mounting at boot time, that works fine this is only when after the system is started.

As for version 1.4.0 it still is happening occasionally but not as bad as when it was at its worst and these discs I am up to in the series are new, where I just took the wrap off them today.