Updated to 15.8.0 on Windows. Had to delete medias.mv.db, now getting a lot of "Can't connect" messages

[wonkey_monkey]

Hi,

15.8.0 on Windows 10

A few weeks ago, while I was still on 13.something, I noticed that UMS was no longer as snappy when browsing from my TV. I was having to wait many seconds each time I opened a directory, with "Reading..." displayed, but eventually the contents would display, and playback was fine.

After running into another issue today - UMS seemingly stripping track numbers from .mp3 files, even though prettify_filenames was off - I decided to update to 15.8.0.

When I first tried to connect, I couldn't open any directory - the TV would display a "Cannot connect" immediately. Following advice on the forum, I deleted medias.mv.db and restarted. This got me into my directories.

But now I find that when I try to open some subdirectories, I again get "Reading..." for a while - even if there are just one or two media files in the directory - and then a "Cannot connect" error pops up.

If I wait a little while and try again, the same directory works - sometimes immediately, sometimes a little longer.

In my logs I'm seeing this error multiple times:

Code: Select all

13:24:53 INFO  Exception in thread "jupnp-sync-protocol 2743-1" java.lang.IllegalStateException: AsyncContext completed and/or Request lifecycle recycled
13:24:53 INFO  	at org.eclipse.jetty.ee10.servlet.AsyncContextState.state(AsyncContextState.java:41)
13:24:53 INFO  	at org.eclipse.jetty.ee10.servlet.AsyncContextState.getResponse(AsyncContextState.java:108)
13:24:53 INFO  	at net.pms.network.mediaserver.jupnp.transport.async.JakartaAsyncServletUpnpStream.getResponse(JakartaAsyncServletUpnpStream.java:69)
13:24:53 INFO  	at net.pms.network.mediaserver.jupnp.transport.impl.JakartaServletUpnpStream.writeResponseMessage(JakartaServletUpnpStream.java:165)
13:24:53 INFO  	at net.pms.network.mediaserver.jupnp.transport.impl.JakartaServletUpnpStream.run(JakartaServletUpnpStream.java:74)
13:24:53 INFO  	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
13:24:53 INFO  	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
13:24:53 INFO  	at java.base/java.lang.Thread.run(Unknown Source)

But it's not one-to-one with the errors I'm seeing on the TV so I'm not sure how related it is. For example, I just triggered the error a few times in a row, but nothing new was written to the logs (in TRACE or DEBUG).

Am I just being impatient? Do I need to wait a while longer for a cache to rebuild? medias.mv.db seems to have been unchanged for the last 15 minutes, but the contents of the "medias" still seem to be updating.

(also there may be a bug on the Old Settings log level selector menu. If I select log level "All", the log says "Changed debug level to OFF". If I select "Off", nothing happens - the menu doesn't even go away).

[wonkey_monkey]

Addendum:

I had an issue with a folder which had two CDs' tracks in it, and it was ignoring the filename and playing by track number, so the tracks were interleaved. Pretty understandable.

I split the tracks out into separate folders, but since doing that UMS is being unreasonably slow to browse.

In the logs, I can see it is finding "New file" but only once every 30 seconds (exactly), so by moving 20 tracks it seems I'm going to be waiting 10 minutes until UMS is usable again.

Is this normal?

[mik_s]

Could you post your logs so I can see what is happening? See the section in red above.

[wonkey_monkey]

As it's now crashed silently with nothing written to the log half a dozen times - even while not play anything - I'm giving up and going back to version 13.

[mik_s]

If it is crashing before it starts then there should still be some logs showing what happened. The logs are at C:\ProgramData\UMS\debug.log
If you are unable to start in TRACE mode then you can force it in that mode by editing C:\ProgramData\UMS\UMS.conf when UMS is not running and set

Code: Select all

log_level =trace

Attach both of those files and I'll be able to see why it is crashing.