Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Having several issues getting all my files to share, or share correctly #1686

Closed
woollarding opened this issue Nov 10, 2021 · 28 comments
Closed

Having several issues getting all my files to share, or share correctly #1686

woollarding opened this issue Nov 10, 2021 · 28 comments
Labels
bug

Comments

@woollarding
Copy link

Nicotine+ version: 3.1.1

Operating System/Distribution: Windows 11

Describe the bug

The first problem I have is that some sub-folders are shared on the same level as their root folder when viewed with soulseekQT but not with nicotine .. if that makes sense, if not have a screen shots. I also have some other issues with some folders showing up as empty even though there are files in them, and I think that is both on nicotine and QT. Also there is the problem that I think may have been addressed already where file names that are too long or something will give an error.. I did try to uninstall and reinstall, but it seems to have saved some of the settings as my queue and info are still intact.. is there something else I need to do to fully remove at least the share settings? any help is appreciated.

Expected behavior

To be able to share files and have them configured correctly or in some cases show up at all.

Steps to reproduce the bug

browse my nicotine share with a QT client

Additional context

share on nicotine

share on QT

Screenshots, logs, stacktraces or relevant information.
@slook
Copy link
Member

slook commented Nov 11, 2021 •
edited

is there something else I need to do to fully remove at least the share settings?

Delete all the files/folders ending in *.db in your ./nicotine user profile directory. This will force a rebuild of your shares from scratch. If you delete your whole profile then Nicotine+ will go to factory defaults.

there is the problem that I think may have been addressed already where file names that are too long or something will give an error..

There have been several improvements to the handling of these issues with share scanner in 3.2.0.dev1. If possible please verify that the problem you are having is resolved (or at least reported in more detail with the improved Debug error logging) in the Unstable branch, because Nicotine+ 3.2.0 will be released soon.

However there are some unrelated issues with PyInstaller that is currently blocking master release to Stable, and may prevent you from installing the Unstable package. Apparently the 32-bit Unstable package is easier to install on Windows 10 at the moment, we haven't tested 11 yet, so this would be appreciated if you are able to test this @woollarding.

@woollarding
Copy link
Author

Thanks for the information. I tried deleting the .db files I could find and then rescanned the share, same result. I tried to install the 32-bit dev version and got 'failed to execute script nicotine' which is what the 64-bit version said as well. Ill try to reset to defaults tomorrow and report back.

@slook
Copy link
Member

slook commented Nov 11, 2021

I tried to install the 32-bit dev version and got 'failed to execute script nicotine' which is what the 64-bit version said as well.

Thank you for confirming that #1665 is also affecting Windows 11, I feared that this was going to be case. A fix for this startup error is in progress #1639 will hopefully address that issue soon.

Ill try to reset to defaults tomorrow and report back.

It's not worth doing that until you can run Unstable, because it's unlikely to fix your missing shared folders in Nicotine+ 3.1.1. Even if it does there's no guarantee that you will not encounter the same bug further down the line, although having said that I suppose it might be interesting to know if the problem arises from the outset or if it's something that occurs later.

@mathiascode
Copy link
Member

mathiascode commented Nov 11, 2021 •
edited

Could you send me the .db files privately (to my e-mail on my GH profile, or another way if you prefer that)?

@woollarding
Copy link
Author

woollarding commented Nov 11, 2021 via email

@mathiascode
Copy link
Member

Thanks, I received them. I'll investigate why the folders appear like this in SlskQt.

Also there is the problem that I think may have been addressed already where file names that are too long or something will give an error

I almost have a working fix for this, but it will probably not be included in the near future. I want to ensure it works properly without breaking stuff like network shares.

@mathiascode
Copy link
Member

The unstable Windows builds are working again. Could you install the latest one, remove the db files and rescan, and see if anything has changed?

@woollarding
Copy link
Author

woollarding commented Nov 13, 2021 via email

@mathiascode
Copy link
Member

Glad to hear it's working on Windows 11. The "Ignoring invalid metadata for file" checks were added in 3.2.0 (the metadata parsing library isn't perfect).

You're welcome, thank you for reporting the issue. :) There are so many large shares with odd files out there that it's difficult to test.

@woollarding
Copy link
Author

woollarding commented Nov 13, 2021 via email

@mathiascode
Copy link
Member

In that case, I think this is a bug in SoulseekQt. Nicotine+ and Soulseek NS display the share without issues.

Does SoulseekQt scan and display your share without issues?

@woollarding
Copy link
Author

woollarding commented Nov 13, 2021 via email

@mathiascode
Copy link
Member

Could you browse the SoulseekQt user in Nicotine+, save the shares list to disk, and send the file to me (located in ~/.local/share/nicotine/usershares/)? I'd like to compare it with the one generated from the Nicotine+ scanner.

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@mathiascode
Copy link
Member

3fb4d32 should fix the issue with folders appearing at root level in SoulseekQt.

@mathiascode
Copy link
Member

b6dfe72 fixes an issue where the rest of the folder wasn't scanned after failing to scan a file in it.

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@slook
Copy link
Member

slook commented Nov 14, 2021

Those are commit references for the repo, they're of no use to you @woollarding

Just re-download and install from Unstable installer packages are generated a short time after every commit.

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@mathiascode
Copy link
Member

I've made some larger changes to the scanner code in order to improve performance (avoid scanning the file system twice).

Could you download the latest unstable build, and:

  • rescan once, and verify that everything looks fine
  • remove the db files, rescan, and verify again?

Thanks! I just want to verify that no regressions were introduced.

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@woollarding
Copy link
Author

woollarding commented Nov 14, 2021 via email

@slook
Copy link
Member

slook commented Nov 14, 2021

Thank you for your assistance with this testing and troubleshooting @woollarding this is very helpful for the other users. If you notice anything else that needs fixing for the next release of Nicotine+ then you are welcome to post on here any time.

it took a while... ...then I deleted the .db again and scanned and it only took about a minute

I have also observed this behaviour, it could be something to do with caching in semidbm, or perhaps drive caching at the OS and/or hardware level.

@slook
Copy link
Member

slook commented Nov 14, 2021 •
edited

would be super helpful if user is able to check info about why they were banned

The mechanisms for the sending and processing of shared file counts statistics is unrelated to this bug. For the latest thread on this topic see #1565, some partial remedies are being considered, such as including the minimum file/folder requirements in the messages N+ sends out. Of course, we have no control over what other clients do. Edit: I think I've slightly misunderstood your suggestion, the topic is confusing to everybody.

Given that all the OP's shared folders files are now visible to users after the successful improvements to the scanner, I think this Bug is resolved for now @mathiascode ?

@mathiascode
Copy link
Member

not sure if this is something to do with this version, but a banned user was not able to view my userinfo .. 11:51:32 User sillybaby is reading your user info 11:51:39 [Chat] Private message from user 'sillybaby': it says "You are banned from downloading my shared files." would be super helpful if user is able to check info about why they were banned, saves a lot of typing heh

It was a somewhat sloppy change in 3.2.0. 616ef28 now shows the ban reason above the user info message instead of replacing it.

Thanks for your help! I'll close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mathiascode @woollarding @slook