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

Database update not opening #353

Open
manichardtiger opened this issue Oct 26, 2018 · 7 comments
Open

Database update not opening #353

manichardtiger opened this issue Oct 26, 2018 · 7 comments
Labels

Comments

@manichardtiger
Copy link

manichardtiger commented Oct 26, 2018

Hi

I recently upgraded from 1.1.2 to 1.2.4 using the How To on the sonerezh website.

Everything went OK (awesome tweaks and improvements btw) and I then tested the new database update feature, which worked beautifully. It found the metadata changes I had made and also the new files that were added to the directory.

I then proceeded to add more music and fix more metadata and tried to update again.. but the update page no longer opens. When you click the update icon/link it simply refreshes the page (and also stops any playback). The same behaviour happens when you try through the settings page -> database update button.

Steps tried:

  • Restarted Nginx; no change
  • Rebooted host; no change
  • Deleted sonerezh directory, untarred again and re-imported previous 1.1.2 database; no change

The issue can be consistently replicated on different computers / browsers .

On a side note, is the update function available in the cli?

Keep up the great work! any help appreciated

Thanks

@MightyCreak
Copy link
Contributor

My guess would be a mistake somewhere in the nginx config, but it's just a guess...

Could you give us your stack versions (nginx, MySQL/PostgreSQL/SQLite, php, etc...) and your nginx server config?

@manichardtiger
Copy link
Author

The thing is.. no changes were made to nginx

Nginx:

server {
listen 8083;
server_name sonerezh;
root /var/www/sonerezh/app/webroot;

index index.php;

location / {
    try_files $uri $uri/ /index.php?$args;
    expires 14d;
    add_header Cache-Control 'public';
}

# The section below handle the thumbnails cache, on the client (browser)
# side (optional but recommended)
location ~* /([^/]+_[0-9]+x[0-9]+(@[0-9]+x)?\.[a-z]+)$ {
    try_files /img/resized/$1 /index.php?$args;
    add_header Cache-Control 'public';
    expires 14d;
    access_log off;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_index index.php;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    include fastcgi.conf;

    # If fastcgi.conf is not available on your platform you may want to
    # uncomment the following line
    #fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

}

Nginx version: 1.6.2
mysql Ver 14.14 Distrib 5.5.60, for debian-linux-gnu (armv7l) using readline 6.3
PHP 5.6.33-0+deb8u1 (cli) (built: Jan 5 2018 18:06:10)

@MightyCreak
Copy link
Contributor

I have around the same configuration, but with an x86 CPU.
Your nginx config seems legit.

I think you can take a look at the logs.
First at the Sonerezh logs in /var/www/sonerezh/app/tmp/logs/
And then at the nginx logs in /var/log/nginx/

You should be able to find something in there when you try to access the import page.

If you still can't find anything, you can also add fastcgi_param CAKEPHP_DEBUG 1; in your ~ \.php$ location. That should give you extra informations (long time I didn't try this one) 😉

Hope it helps!

@manichardtiger
Copy link
Author

Thanks!!

Turns out that Sonerezh was trying to scan .Trash-1000 that was created after I deleted some tracks:

2018-10-31 11:11:11 Error: [UnexpectedValueException] RecursiveDirectoryIterator::__construct(/export/BANANA-MUSIC/.Trash-1000): failed to open dir: Permission denied

but it didnt have permissions to do so

all is ok now, Thanks!

@MightyCreak
Copy link
Contributor

Excellent ;)

@lGuillaume124
Copy link
Contributor

Does Sonerezh should skip directories prefixed with a dot?

@MightyCreak
Copy link
Contributor

I would be inclined to say yes, since dot files/dirs are hidden by default.
But it would also be useful to have a little bit more information directly on the client when something's wrong, instead of having to dig into the log files to guess what could have been wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants