After applying the March 2018 update (and having been previously up-to-date), I have two issues that I have not been able to resolve (after ensuring that all other Pi software is up-to-date):
Although I have SMB access on my Windows machine, my BluRay player (Oppo), which has accessed SMB from this Pi for years, is caught in a failed login loop. I’ve tried a number of solutions, including changing maximum SMB version to 1 (or none), but nothing has worked.
I am getting regular audio dropouts, even from 44.1k mp3 files, where I never got dropouts before. I’ve tried increasing buffersize, but the dropouts are still there.
I’m a little frustrated that my nice and stable system becomes regularly not nice and unstable after updates, and I’m inclined to just stop updating if I can get things working again. If there’s no fix in the mix for the above two issues (which I would consider major, for me), is there a clear, published doc for downgrading (I didn’t find one)?
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Thanks for your understanding. We hope that we can help you get up and running again shortly.
Conversely, there are unfortunately no widespread reports of this issue, which is why there’s no fix.
We’d need more information from you to be able to work out what the issue is.
I’d recommend turning off updates if you are continually experiencing problems with them, as well as verifying your peripherals as this is certainly unusual. Can you let us know which updates in particular have been problematic for you?
I’ll have to search for updates that were problematic… there was one a few months ago that was fairly catastrophic in terms of functionality but relatively easy to fix (once a solution was found, which wasn’t easy or fast – had to change to default Kodi skin instead of OSMC and turn off overclocking).
Overclock settings are accessible under My OSMC independent of a skin.
Be careful with overclocking. I can’t pull your logs from September 2017 as they have since expired; but I suspect you either had a problem with the overclock values you set at the time or your PSU was not up to scratch. What PSU are you using?
Your logs:
Are not debug logs
Don’t show any attempt to play any content
Show a large number of inaccessible directories. This should be cleaned up first.
Please read the support page so that you can provide us with the correct information.
I have no interest or need for overclocking and it has been off for quite some time. I feel pretty confident that it has nothing to do with current issues.
I apparently turned debugging off and so will turn it back on and replicate the issues.
I have no idea why there is any attempt to access those directories – the music library was recently moved and has been cleaned.
The file I tested is an m4a file, which is one that gets a lot of plays (“white noise”) and has been dropping out the most since the update.
I attempted to access SMB via the Oppo. I get a list of directories (confirmed up-to-date) but am prompted to enter username / password to enter any of those directories. Always fails.
The Oppo’s firmware has been the same for months. No new firmware messages. The SMB issue started immediately after March 2018 OSMC update.
Overclock settings are accessible under My OSMC independent of a skin.
I realize that you might have meant something different than what I originally understood, so it’s worth pointing out:
My problem from September 2017 required two steps to fix: 1. Turning off overclocking. 2. Using the default Kodi skin instead of the OSMC skin. For some reason, the latter was correlated with sad face failures when the system was idle for certain durations.
It seem like you thought that I was saying that I needed to change the skin to access the overclock settings, which was not the case.
Samba hasn’t changed since December 2017, so that rules out a Samba update via OSMC.
I believe that’s a known bug with some Samba shares, but this has been unchanged for almost two years. Entering the username and password when you define the source will remedy the issue. This behaviour wouldn’t have changed across OSMC updates; but how you access the share may have changed.
For the audio file: did you try play it from the home folder instead of mounted storage?
Re overclocking: the issue may not have been caused by the overclock values, but rather a problem with your power supply. An overclock and an attached disk could be problematic for insufficient PSUs.
Well, we seem to be at an impasse, because nothing has changed regarding how the share is accessed, and it was accessed a-ok immediately before the update. When you say “when you define the source”, what exactly do you mean?
If this is really an impasse, I would like to at least try reverting to the previous version. And, if there is a document on the best way to do so, I’d be really appreciative of a link (I can figure it out, but I’ve invested a lot of time just trying to get things back to where I already had them, and I’d really love to just have some instructions that are known to work).
I want to focus on the SMB right now, because I can troubleshoot the PSU if necessary, but the SMB problem is mysterious.
So, again, I’m not sure what you mean: “when defining the source under Kodi”. Perhaps it’s me who isn’t being clear: I use the Pi / OSMC / Kodi as the SMB server and the Oppo as the client. As far as I can tell, there are not a whole lot of configuration options available for Samba in OSMC and Kodi regarding the server.
Well – the PSU is one of the most crucial parts of the system. If your PSU is not up to scratch you can have issues with playback, network drop-outs etc. Covered here: Frequently Asked Questions - Raspberry Pi - OSMC
Possibilities are:
You are not entering the username and password (both of which are osmc)
The Oppo doesn’t ‘speak’ the same SMB dialect that the server (OSMC) offers.
I suspect the Oppo is more locked down, but /var/log/samba probably has some details when the connection fails that would give you insight.
I think that I’ve stated it several times already: I’ve used the Oppo for years with this exact configuration. It spoke the same dialog and has had the same u/p that whole time, and it just stopped working exactly after the update.
And I understand the importance of the PSU and how that interacts with the Pi. We can let that go for now.
Oppo uses SMBv1. It is disabled as default in Windows 10 (From Build 1709 and newer) for security reasons. Any share you have uses SMBv2 or v3 (which is not supported by the Oppo (yet…) ) You have to enable it manually.
That’s why Oppo won’t be able to connect to a Windows machine or OSMC system.
You can enable SMBv1 by editing your SMB.conf and adjusting the minimum version. We raised the minimum SMB version for security reasons.
I’ve checked your logs to see why you’re only experiencing this problem now. It looks like you last updated in December (pre-Stretch). Now you have updated to the March update which uses Stretch as a base. So it’s not the March update that broke it per se, but the security improvements made to the Samba server, which were released at the end of December, and only received by you on 27th March.
This change of behaviour isn’t a bug. It’s intentional. Either lower the SMB version (security risk) or ask the vendor for a firmware update.
So, to be clear, if I decided to do so, I would enable SMBv1 by adding:
min protocol = SMB1
?
There’s nothing in the current smb.conf specifying a minimum version.