Audio dropouts, no SMBv1 access on Oppo after Stretch update

Here are the logs: https://paste.osmc.tv/jetoxikaku

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.

Ideally, we want to see a debug log where:

  • You cannot access an SMB share
  • You experience dropouts with an MP3 file

Do you know if the Oppo has received a firmware update post. WannaCry?

I’m not sure this will be much more helpful, but: https://paste.osmc.tv/ginaxehazo

  1. 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.
  2. 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.
  3. 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).

Instead of browsing, you would add the password when defining the source under Kodi.

I’m surprised that it worked before (although the nature of this issue is intermittent).

You can certainly downgrade by reinstalling from osmv.tv/download, but I’m not convinced this will resolve the problem for you as explained above.

It’s still unclear:

  • Which PSU you’re using (will be relevant to OC settings, and important to know if you have a disk attached)
  • If playing the music from the Home directory improves the situation.

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: https://osmc.tv/wiki/raspberry-pi/frequently-asked-questions/

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.

Have you looked at the log as suggested?

That’s unlikely after June / July 2017.

Most likely you need to re-enable SMBv1 (be aware this is a security risk) in smb.conf by setting min protocol.

Setting SMB version in Kodi won’t do anything, because that only affects Kodi’s operation as a client.

From http://7tjob.com/forum/149-blu-ray-players/2676801-official-oppo-udp-203-owner-s-thread-909.html#post55911218

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.

I set up NFS on the PI, and the Oppo can read it. Thanks for your help.

This is nearly identical to my experience on a 1st-gen rPi. After the March 2018 upgrade, SMB became unstable (would sometimes hang) so I switched to NFS and things were fine.
Then, a week or so later, playing video also started to hang the player. Loading the file I was streaming over NFS onto a USB stick, plugging that into the rPi, and playing that way also started to freeze/hang (eliminating the network, NFS vs. SMB, the fileserver, etc).

At that point I realized that the PSU (tiny wall wart) that I’ve been using for a few years for it had likely aged out, or the power requirements for the system post-upgrade were slightly higher. Swapped in a new PSU with better specs and everything is fine again – the same videos that would hang even playing locally were now flawlessly streamed over NFS. I haven’t tried going back to SMB yet.

…Steve

1 Like

In many ways, I prefer NFS for this specific task, so it was probably a fortunate event overall. The power supply issue is common, but mine checks out fine, which is why I didn’t want to continue down that path. But, it’s true that all sorts of things can go (terribly) wrong with a weak / unstable PS and an external drive.

NFS is definitely a better option