[milli.maci]

I'm running Kodi since v17 on Manjaro Linux. v19.4 was flawless but two things broke after updating to v20. Now I've updated to v20.1 but things didn't improve.

- Audio device isn't kept alive anymore. Settings is set to 'always' but my soundbar now goes to sleep after it's own timeout (10 minutes).
I've seen others reports about this but apparently the code for this hasn't been updated for years so my guess is that something goes wrong with the config during the update
(strangely this setting was blank after the update but setting to always doesn't work).

- Scan video library took less than a minute and clean less than 30 seconds. Now scan takes over 30 minutes and clean a couple minutes.
I've checked the log and this is recurring constantly: error <general>: Unable to lookup host: 'DiskStation'.
Which is weird because all videos still play, the smb share still is accessible in Kodi and new videos are eventually added after this lengthy process.
I don't seem to be able to find the real cause. I've tried SMBv2 and v3 already (not eager to go to v1).
I was running kernel 6.2 but now went back to LTS 6.1 but also no change.


Thanks in advance for any help!

https://paste.kodi.tv/irexitahoy.kodi

[wsnipex]

your box clearly cannot resolve "DiskStation", make sure your DNS is handling that correctly, or add an /etc/hosts entry.

[milli.maci]

If it can't resolve "DiskStation" then how can it still play everything, still add videos to the library and I also can browse the DiskStation share within Kodi.

[izprtxqkft]

additionally ip addresses are far more recommendable than hostnames which can be hit or miss.

your log doesnt show any playback to determine it was in fact able to play from "DiskStation"

what is the output from your console for "ping DiskStation"?

[fritsch]

Keep Audio alive was fixed.

[milli.maci]

@jepsizofye 
I know that using the IP is more of a 'sure thing' but Kodi is still revolving that share. It's just spawning all those errors, causing scanning to take forever.
To be more clear, I'm using Kodi's built-in SMB functionality. Even though I'm auto mounting my network share as a systemd unit within Manjaro, I'm not using that in Kodi. So it makes no sense for me to ping it in konsole.
I'll make a new log tomorrow just to prove it's still playing everything. I mean I just finished watching a movie.

@fritsch Clearly not fixed at my end.

[izprtxqkft]

ok since you clearly dont want help (youve ignored it twice from two people) i will just wish you well

best of luck

[milli.maci]

How do I not want help? Now I'm confused?
You asked me ping that share in Konsole and I said that I'm using Kodi's built-in SMB. 
Does Kodi have a built-in console because if it does, I don't know about it.

[fritsch]

@jepsizofye 
I know that using the IP is more of a 'sure thing' but Kodi is still revolving that share. It's just spawning all those errors, causing scanning to take forever.
To be more clear, I'm using Kodi's built-in SMB functionality. Even though I'm auto mounting my network share as a systemd unit within Manjaro, I'm not using that in Kodi. So it makes no sense for me to ping it in konsole.
I'll make a new log tomorrow just to prove it's still playing everything. I mean I just finished watching a movie.

@fritsch Clearly not fixed at my end.

Even your log is clear on that. You see exactly and 100% one call to "OpenSink" throughout the entire livetime of your kodi log ... nothing is opened / closed again. Whatever happens for you is outside of kodi.

[milli.maci]

Well in my naive mind I thought to present a clean log. So the log is just Kodi booting, scanning and closing.
I didn't know I would be put on trial. 

This morning I recorded a video to show that I'm not making things up: https://drive.google.com/file/d/1XNMwPsd...sp=sharing

As you can see, smb://DiskStation is just working even though the log is full of not being able to resolve it and library scanning taking over 30 minutes.

[izprtxqkft]

well anyway i was trying to figure out which way DiskStation is being resolved with the ping in console but you didnt feel it relevant

ping: DiskStation: Name or service not known; would have indicated whether or not linux or netbios names are being resolved in whichever scenarios are failing or succeeding

http://www.differencebetween.net/technol...nd-netbios

you can add the ip address to hosts in kodi advancedsettings.xml - https://kodi.wiki/view/Advancedsettings.xml#hosts

failing that adding it to /etc/hosts would have worked as already suggested

[milli.maci]

I'll give that a go and add the IP address to hosts.
What would be the reason that Kodi suddenly would requires this?
Doesn't any of you find it strange that I get that error, even though the network share's name is still clearly resolving?

I'll explain why I think the ping in Linux Konsole is irrelevant and correct me if I'm wrong (my info might be out of date).
As far as I know, Kodi doesn't use the Windows or Linux SMB implementation but uses its own separate internal system as a leftover of being derived from XBMC.
As such, I didn't think that it's important that it resolves in Manjaro. It needs to resolve in Kodi.
I already knew that 'DiskStation' isn't the issue in the OS because this machine also runs a Plex server without issues.

[izprtxqkft]

i use ip address access and set my nas ip as static in my router so i can only guess as to hostname behavior

on my nas, it has a hostname and a netbios name, the netbios name is served by nmbd from the samba package

the hostname is served by linux as a .local, so i can only access <hostname>.local from my other linux machines because in console it does not use nmbd lookup

the different methods used in kodi are unfamiliar to me

so depending on how buffalo does their setup, nmbd may or may not work or the dns may or may not, one may serve ipv6 only where ipv4 is needed or any number of other scenarios


so in order to determine how DiskStation works, i wanted to know if it resolved - if yes then a dns server is in play, if no nmbd is in play, following that i would have had a better idea where to go

[milli.maci]

Update on this issue (couldn't post sooner because of hack).

I think some didn't really understand my issue but I won't go into that again.
Anyhow, I downgraded back to 19.4 and both issues solved themselves, so something goes wrong with the upgrade.
In 19.4 scan takes less than a minute and soundbar is kept alive correctly. 

I've included 19.4 and 20.1 logs.
Logs were too big for hastebin.

19.4: https://drive.google.com/file/d/1zeeQ5rV...sp=sharing
20.1: https://drive.google.com/file/d/1wrSEmEz...sp=sharing

[milli.maci]

This is a more complete 20.1 log: https://drive.google.com/file/d/15KfinVW...sp=sharing