SD Cache location using Android 4.2.2

[mychickensonfire]

Firstly, great app. I've been happily using it for years.

I've just bought a S4 mini and have been attempting to cache my music on a 64 GB SD card. The phone is runnning 4.2.2, but I have ben reading several posts and other general information about 4.4.

Dsub wants to cache my music on the phone memory at

Code: Select all

/storage/emulated/0/Android/data/GitHub.daneren2005.dsub/files/music

By trial and error I worked out that it would accept. (Gives an invalid cache location error otherwise)

Code: Select all

/storage/extSdCard/Android/data/GitHub.daneren2005.dsub/files/music

I would then attempt to sync or cache a playlist and it will download a few songs and then stops. Dsub then gives me a message about the wrong cache location, 4.4, etc and reverts to the phone memory location above.

Does any know why this is happening if I'm running 4.2.2? I've tried every other directory path using my googlefu, but dsub tells me they're invalid.

Any ideas?

EDIT:
I've just run into the same problem with the ultrasonic and subsonic apps, so it's an android problem. I'm just confused that people have been able to get the cache working on 4.4, yet I can't on 4.2.2????

[daneren2005]

DSub actually tries to see if it can write to that location before giving that error, so it means that for some reason the writes there are failing. Some things I can think of to try:

1) Make sure the SD Card isn't dieing.
2) Make sure the SD Card isn't running out of room.
3) Make sure you are actually on 4.2.2. I believe that phone is upgradable to 4.4.

[mychickensonfire]

Thanks for the response.

1. It is a new SD card, but I have ordered a new one to be certain.
2. Plenty of space left.
3. Unfortunately my version of the mini hasn't got it yet, but apparently it is in testing.

[troycarpenter]

This is the most frustrating part of this app. I want my music to be in a common directory on my SD card so all music programs can access it. I have a modified ROM that doesn't enforce the SD card writing rules, but yet DSub will not let me put the cache file where I want it. Oh, sometimes it looks like it works, but after some time DSub eventually resets the directory. I even get the problem where if I move my files into the directory DSub wants, it still complains at startup and resets to the default, which is the exact same directory.

I have tried moving the app to the system folder, but that doesn't work either. I've also eventually had the problem when using internal storage instead of my SD card.

This causes massive bandwidth usage because once I get the error, it changes the cache location and all the songs have to be cached again.

I can understand forcing it for those without root access that can fix Google's security improvement, but for those of us who can bypass Google's restrictions, we should be able to set the cache directory wherever we want without DSub thinking there is a problem.

[daneren2005]

This is the most frustrating part of this app. I want my music to be in a common directory on my SD card so all music programs can access it. I have a modified ROM that doesn't enforce the SD card writing rules, but yet DSub will not let me put the cache file where I want it. Oh, sometimes it looks like it works, but after some time DSub eventually resets the directory. I even get the problem where if I move my files into the directory DSub wants, it still complains at startup and resets to the default, which is the exact same directory.

I have tried moving the app to the system folder, but that doesn't work either. I've also eventually had the problem when using internal storage instead of my SD card.

This causes massive bandwidth usage because once I get the error, it changes the cache location and all the songs have to be cached again.

I can understand forcing it for those without root access that can fix Google's security improvement, but for those of us who can bypass Google's restrictions, we should be able to set the cache directory wherever we want without DSub thinking there is a problem.

DSub isn't doing any special check for what version you are on. It is checking to see if it can write to the directory. If it cannot, it resets the location to the default. If you are getting that error on startup, something else is going wrong. The file permissions should not be arbitrary like that.

Edit: Doing a quick inspection and some googling, I found a possible logical problem. I thought createNewFile returned false if it failed, but it actually returns false if it already exists. The only case I can think of for it to reach this case is if something is going wrong in the underlying system where the delete is failing, but it could still be the root of your issue. Send me a email at dsub.android@gmail.com and I can send you a test apk to see if it fixes your issue.

[troycarpenter]

Will there be a new beta soon with these changes? I went ahead and let the Play Store upgrade DSub back to 4.7.6 to see if I could make the problem happen in the unmodified load and see if those files were left in the directory afterward (and see if deleting them manually will allow it to work again). No luck thus far.

[daneren2005]

Probably in the next day or so. I put out that beta soon after the last release to test a few targeted things which I thought had a high chance of causing people issues. The newer things I haven't been as worried having it validated.

[troycarpenter]

Ok, running 4.7.7, got in the car this afternoon and fired up Dsub. Got the notification that my cache location was no longer writable and it reset it to default. I went to the cache folder and sure enough the confirmwrite or whatever the file used to check writeability was there. I deleted the file, re-ran DSub and had to change the cache directory back to my preference. Haven't had trouble since.

I hit the "send log" function, but just like before, the logfile it generated to send was empty, so I didn't send.

[troycarpenter]

Just another note that I had it again on 4.7.8 just yesterday. Fixed same as before.

[daneren2005]

If the system is not letting the app delete a file it created itself, then that is a system issue and I can't think of anything I can do to fix that unfortunately.

[troycarpenter]

As long as there's a workaround...I know what file to look for and delete now. Just need to remember that Dsub will have changed the directory and I need to change it back.

I know this adds work, How about a retry mechanism? If the delete fails, is there anyway to know that and try again? I would rather delay the app startup slightly when this happens instead of having to quit, fire up a file manager to delete the file, then restart dSub and change the cache. A bit drastic, but if that doesn't work as a normal user, maybe a super user option to force the deletion of the file.

This is with a Galaxy S3 and I've tried and seen it at least once on various Cyanogen based ROMs. My wife uses stock ROM on her S3, but she doesn't use dSub a fraction as much as I do (I spend more time in the car than she does) and hasn't seen it, but given that I've only seen it twice in the hundreds of launches I've done, it's pretty rare anyway.

[daneren2005]

I can definitely make it retry, though I'm not sure it would make any difference. Before didnt you say putting the location back was rejected until you manually deleted the file? That seems to me that no number of retries will fix it since the system is saying DSub isn't allowed to delete it at any time.

Sent from my Nexus 5 using Tapatalk