After upgrading to 2015-09.2 no TV Show information anymore (RPi2)

After upgrading to 2015-09.2 from 2015-08.1, no more TV Show information is collected. The information that is still there will remain, but no more new TV Show information will be added. Going back to 2015-08.1 as that version is working correct.

Has anybody else seen the same behavior?

What scraper are you using?

Debug Log files, we need them.

Kinda yes.

Here’s what I managed to find out so far. In my case, it seems as if the HDD somehow isn’t made available to OSMC. As in not visible in the file manager BUT actually mounted to the mountpoint specified in fstab. So if I ssh to the RPI2 I can perform operations on the drive, which is a 2TB USB3 Seagate Backup Slim drive by the way…

Library updates are coming up empty (although there is new stuff), at the same time on library cleanups OSMC offers me to remove my movie folder as well as my TV shows folder which is consistent with OSMC not being able to find media files…

The strange thing is though, this only happens sometimes. If you boot OSMC and the HDD is in the file manager you’re good. Otherwise the stuff I just explained happens.

I went through the logs and found this line that raised my attention:

Oct 03 18:21:19 osmc udisks-glue[275]: Device file /dev/sda1 inserted
Oct 03 18:21:19 osmc udisks-glue[275]: Trying to automount /dev/sda1...
Oct 03 18:21:20 osmc udisks-glue[275]: Failed to automount /dev/sda1: Error mounting: mount exited with     exit code 1: helper failed with:
[    4.158389] sd 0:0:0:0: [sda] 3907029167 512-byte logical blocks: (2.00 TB/1.81 TiB)
[    7.454803] sd 0:0:0:0: [sda] Write Protect is off
[    7.454835] sd 0:0:0:0: [sda] Mode Sense: 4f 00 00 00
[    7.455395] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    7.473958]  sda: sda1
[    7.477188] sd 0:0:0:0: [sda] Attached SCSI disk
/dev/sda1       1.9T  1.4T  442G  77% /mnt/SEAGATE

My fstab entry being:

UUID=55B9-F7B1  /mnt/SEAGATE exfat   rw,noatime,nodev,nosuid,fmask=0111,dmask=0000,uid=1000,gid=1000,nofail,uhelper=udisks   0   0

Optionwise I was trying to resemble the line that OSMC builds during automount of a exfat formatted drive. Might be silly, even wrong, but that was the motivation.

Scraper wise I’m on the defaults. TMDB for movies and TVDB for shows. I was fine on the pre September builds. Furthermore this is a fresh installation of the 2015.09-2 build.

I am happy to upload the logs and apologize if this is considered hijacking the post. Might be related might be something entirely different.

@cloggy: You might want to check if your HDD is visible in the file manager… Just my 2c


Please post your entire system journal taken during a boot when the drive does not appear in Kodi - the log entry you found is interesting, because udisks-glue should not be attempting to mount a drive that was already mounted in fstab, suggesting that the fstab mount failed, thus udisks-glue decided to “have a go” at mounting it. (And it too failed) Unfortunately what we need to see comes earlier in the log so we need to see the whole log.

Sorry, but I went back to 2015-08.1 so cannot provide the logs. However, I’ve seen that more issues have been reported after users upgraded to 2015-09.2 update…or is it just me who has noticed it?
For now, I’ll stick to 2015-08.1 and have disabled the updates. I hope it is not a problem to skip the September updates and wait for the updates of October to become available.

@bfqrst: my TV Shows are stored on my NAS server and I use NTFS to access these files. This has never been a problem until 2015-09.2 and it seems that you ran into the same issue I had with your 2015-09.2 installation. And yes, I used the same scrapers as you do (the defaults TVDB for TV-Shows). So, the only difference between your and my environment is that my TV Shows are on my NAS server and yours on an attached HDD. I don’t know if you have noticed it but updating the library with TV Shows goes lightning fast…all folders/shows are found but not a single TV Show is actually updated. With the pre September version, you can see that the update goes much slower and for folders with many episodes, it takes some time to get all the information.

…I suspect the perceived speed comes from the share not being actually scanned :sweat: (or updated so to speak. If there is nothing to update because the share is missing, then well, it all goes fast…). Anyway, I start to think our issues might be related after all.

Here we go. I took me a couple of reboots (maybe five or so) to actually run in the situation again where the HDD doesn’t show in the file manager.

With debug logging being enabled, here is the entire log:

Hope this helps. Please let me know if I can assist.

Thanks guys.

Oct 03 23:00:45 osmc udisks-glue[274]: Failed to automount /dev/sda1: Error mounting: mount exited with exit code 1: helper failed with:
Oct 03 23:00:45 osmc udisks-glue[274]: mount: only root can mount UUID=55B9-F7B1 on /mnt/SEAGATE

I guess it would help the troubleshooting if you would show your fstab entry for that disc and also ls -lah /mnt

…sort of did that in post number 3… :wink:

As for the ls -lah /mnt

osmc@osmc:~$ ls -lah /mnt/
drwxr-xr-x  3 root root 4,0K Sep 30 18:10 .
drwxr-xr-x 23 root root 4,0K Sep 30 16:36 ..
drwxrwxrwx  1 osmc osmc 128K Jan  1  1970 SEAGATE 


Hey guys,

I don’t mean to rush or anything, but is this being looked at? I’m happy to assist where I possibly can…

Thanks a ton

I’m afraid we ended up at the bottom of the pile. :worried: …but don’t worry, more users who have upgraded to the September version must be seeing the same symptoms as we do…
I’m going to wait till the end of October and if it hasn’t been resolved by then, I’m going to install OpenELEC or XBian…

They’re not. We have over 150,000 users who have upgraded to the September update and only a couple of reports here, so I’m inclined to believe it’s something local or hardware related.

That may be your best bet. You haven’t provided a log or any instructions for us to reproduce the issue. Until we can confirm this is indeed a bug and how to replicate it, we cannot work on a fix.

FWIW I removed the nofail option from my fstab (postet below)

and from what I can see the reboots are fine now. Meaning I got the HDD correctly in OSMC. Still, left arrow -> Update library won’t find any new TV shows. Nor does the Update library on startup feature. (Which did in the previous OSMC iteration and is enabled in the settings).

What actually does work, this much I can say, is navigating to Videos -> Files -> [YOURHDD] -> [YOURSHOWFOLDER] and hitting Scan for new content.

I was under the impression that Update library and Scan for new content are the same buttons under the hood.

One hint @sam_nazarko , @cloggy didn’t provide any logs, but I did. So maybe that helps.

Thanks people

@sam_nazarko: I cannot provide logs as I went back to 2015-08.1 (mentioned this before) after struggling for 2 evenings. The September update happened about the same time I installed a new Synology server and I initially suspected incorrect settings in the Synology hence I spent 2 evenings trying to find the issue in the Synology and at the end I was really fed up when I discovered that 2015-08.1 did not have the reported problem so I did not want to spend another evening to go to 2015-09.2 to provide you with logs especially as @bfqrst reported the same problems and already provided all the requested information. The only difference with his and my environment is that he has his TV Shows stored on an attached USB drive while I have mine on the Synology server. Hope this clarifies why I did not provide the requested information … (as you already have everything provided by @bfqrst… for which I’m very thankful!)

@bfqrst: does this mean that after a ‘Scan for new Content as you described fixed the issue of missing TV Show (and quite likely also Movies) information?’ If so, then there is really a change of behavior introduced with the September update and it is a real deviation from previous versions.

Strangely enough the movies never suffered from this issue. At least as far as I can tell.

When I boot the Pi all I can see flashing by is compressing database. When I do the Scan for new content thing in Videos -> Files, I see in the lower right corner Getting information from TVDB (don’t recall the exact wording) and the infos are getting updated.

Just so we are on the same page @cloggy it doesn’t fix the issue permanently it just scans the source that very moment. The problem as such persists.

EDIT 19:22: I can confirm that on a fresh installation the issue is the same as on a updated installation…

EDIT 19:43: I can exclude the 7 port USB 2.0 hub to which the HDD was initially attached to… Direct USB connection with max_usb_current on renders the same negative result… Furthermore I can confirm that new movies are correctly detected on reboot. So, yeah, it’s tv show thing…

hello @bfqrst many thanks for the update! This means that I’m going to stay on 2015-08.1 for the time being. Still very strange that we seem to be the only ones so far that have noticed this problem (or at least have reported it). I’ve even searched on the KODI forum but haven’t found a hit so I think it is related to the OSMC September update.

…strange indeed. Well, let’s be honest, one can work around it as I found out, but the perfectionist in me is not satisfied. :smile: . I’m with you on this… I almost can’t believe it that no one else has this. I can reproduce it in a jiffy. Even on a fresh installation…

Anyway, it’s a nice piece of software and it comes at an unbeatable price tag so who am I to complain? So thanks to those who actually contribute ones and zeros to the project!

Have a good one

Hi there,

It is important that we fix this.

This is a very significant difference. We are currently aware of some ‘deficiencies’ in the OSMC automounting system for external media, but this only affects storage attached via USB. @DBMandrake is working on improving that this month. If both reports were with USB attached media, I would have assumed that this was caused by our current UDisks implementation and left it at that. But it seems to not be so clear cut.

I checked @bfqrst’s log. Just to confirm, as @bfqrst appears to be trying to scan from /media which suggests USB media. @cloggy, are you having issues with NFS shares (storage not directly attached to the Pi?)

In @bfqrst’s log, I saw that some scanning was skipped due to using the fasthash algorithm. Shot in the dark, but can you try this (via SSH) – just copy and paste:

echo -e "
</advancedsettings> " > ~/.kodi/userdata/advancedsettings.xml
sudo systemctl restart mediacenter


Thanks for your input Sam. Sorry that didn’t cut it. Same behavior on manual scan as well as on reboot…

But here’s what I learned. Apparently Update library and Scan for new content are not the same under the hood. Found this statement on Reddit. Sure sounded like fasthash could do the trick.

`Some exfat formatted drives don’t seem to work all the time with the “fast hash” system that kodi uses to see if there are changes or not. Fast hash allows Kodi to check for updates without checking every single file and folder by using a hash system. You can manually disable this using an advancedsettings.xml file, which should make it work like it did in Gotham:

You can also manually trigger a full update regardless of hash by using “scan for new content” when selecting a specific video file source. Some library update add-ons might also trigger updates that skip the hash check.`

Could it be the noatime option in the fstab? But then again, movies are working just fine…