Android will ignore permission request and will not show the request dialog
if the user's action implies "don't ask again."
This leaves the app in a crippled state and the user confused.
Google says "don't try to convince the user", so it returns false for `shouldShowRequestPermissionRationale`.
To help the user proceed, we show the `Request permission` button only if `shouldShowRequestPermissionRationale == true`
because there's a good chance the premission request dialog will not be ignored.
If `shouldShowRequestPermissionRationale == false` we instead show the "rationale" message and a button to open
the app info dialog where the user can explicitly grand the permission.
The output gets the standard MPD log format with domain curl and a timestamp.
Using CURLOPT_DEBUGFUNCTION that is only called when CURLOPT_VERBOSE is in effect
when MPD log level is verbose.
The BlockingCall() in InitUringInputPlugin() did not work because the
EventThread was not yet started. This was never noticed until commit
e309941646e which enabled `IORING_SETUP_SINGLE_ISSUER`, and suddenly
the kernel refused to accept io_uring_submit() calls from the
io_thread because io_uring_setup() had been called from the main
thread.
This reverts commit b49cfe96f406bf0b750b7a1ea73609905d606335. It was
a bad idea because it broke signal handlers. I need to find a better
way to fix io_uring intialization.
Once a NFS request fails with NFS4ERR_EXPIRED, the whole connection is
broken and we need to open a new one. I wish libnfs would report this
to us as a connection-level error, but instead only the one request
fails; therefore this workaround is an ugly kludge.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2175
The resume/seek was received asynchronously and meanwhile an error
might have occurred that needs to be handled.
This fixes another NFS-related crash bug.
libFLAC tries to keep on seeking a stream even after a (fatal) read
error has occurred. Let the DecoderClient decide whether proceeding
is possible.
This fixes a crash bug when playing a file over NFS and the NFS
connection fails.
When running with stdout output to debug the server
or misbehaving clients, it is useful to have the timestamp
to detect timing issues and response times.
Especially when opening and playing online sources that
block the connection thread sometime for a significantly
long time that makes the client-server unresponsive
and cause timeouts in clients.
This fixes a regression triggered by commit e309941646e0ff1b6 -
IORING_SETUP_SINGLE_ISSUER broke because io_uring_setup() was called
fromm the main thread, yet io_uring_submit() in the I/O thread. This
is because the I/O thread was not yet started when
InitUringInputPlugin() was called, and BlockingCall() was invoked
synchronously in the main thread. This has always been wrong, but was
never noticed.
