sonerezh icon indicating copy to clipboard operation
sonerezh copied to clipboard

Database update not opening

Open manichardtiger opened this issue 7 years ago • 7 comments

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

manichardtiger avatar Oct 26 '18 09:10 manichardtiger

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?

MightyCreak avatar Oct 26 '18 13:10 MightyCreak

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)

manichardtiger avatar Oct 26 '18 13:10 manichardtiger

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) :wink:

Hope it helps!

MightyCreak avatar Oct 29 '18 12:10 MightyCreak

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!

manichardtiger avatar Oct 31 '18 09:10 manichardtiger

Excellent ;)

MightyCreak avatar Oct 31 '18 12:10 MightyCreak

Does Sonerezh should skip directories prefixed with a dot?

lGuillaume124 avatar Nov 01 '18 16:11 lGuillaume124

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.

MightyCreak avatar Nov 01 '18 16:11 MightyCreak