search

AntennaPod / AntennaPod

A podcast manager for Android
https://www.antennapod.org
GNU General Public License v3.0
6.42k stars 1.41k forks source link

Updating to newer android or switching sdcard will break AntennaPod data location #1777

Open SoundEater opened 8 years ago

SoundEater commented 8 years ago

AntennaPod version: 1.5.1.4

I updated my phone from Android 4.4.4 to Android 6.0.1 and i got an unable to access sdcard error. Then after i copied my media files to a new sdcard i got the same error.

When is this a problem:

After some troubleshooting i found and solved the problem manually: original location: android 4.4.4 /storage/sdcard1/Download/AntennaPod restore location: android 6.0.1 /storage/1234-ABCD/Download/AntennaPod (sdcard error) working location: android 6.0.1 /storage/1234-ABCD/Android/data/de.danoeh.antennapod/files new location: android 6.0.1 /storage/4321-DCBA/Android/data/de.danoeh.antennapod/files

Two files need to be updated: /data/data/de.danoeh.antennapod/databases/Antennapod.db /data/data/de.danoeh.antennapod/shared_prefs/de.danoeh.antennapod_preferences.xml

>> Antennapod.db update "main"."feedimages" set file_url = replace (file_url, '/storage/sdcard1/Download/AntennaPod', '/storage/4321-DCBA/Android/data/de.danoeh.antennapod/files'); update "main"."feedmedia" set file_url = replace (file_url, '/storage/sdcard1/Download/AntennaPod', '/storage/4321-DCBA/Android/data/de.danoeh.antennapod/files'); update "main"."feeds" set file_url = replace (file_url, '/storage/sdcard1/Download/AntennaPod', '/storage/4321-DCBA/Android/data/de.danoeh.antennapod/files');

>> de.danoeh.antennapod_preferences.xml

/storage/4321-DCBA/Android/data/de.danoeh.antennapod/files /storage/4321-DCBA/Android/data/de.danoeh.antennapod/files/media/somefile.mp3

Prefered fix: Scan mmc/sdcard for 'cache;export;import;media' and update location accordingly. On failure allow user to enter folder manually

mfietz commented 8 years ago

If it is that easy, we accept pull requests... :>

SoundEater commented 8 years ago

I'm not a programmer mate :/

SoundEater commented 8 years ago

Found the problem, i think you have to set the location through the "documents provider" as of 4.4.4 and up: https://developer.android.com/reference/android/provider/DocumentsProvider.html https://developer.android.com/guide/topics/providers/document-provider.html

RalfJung commented 8 years ago

I can confirm the problem: After re-configuring the storage location (no matter whether Android was updated or not), the old downloads are not used by AntennaPod. Even if I move the files over manually. AntennaPod will still show them as being downloaded, but when I click the "play" button, nothing happens. After refreshing the view, I get a "download" button -- so I have to re-download the episode. The old files are still around though; I had to manually delete them.

In particular, when updating from Android 5.1 to 6.0, I had to re-configure the storage location, which triggered the above bug. But the same issue arises when e.g. switching from the internal storage to an SD card.

mhellwig commented 5 years ago

is this something that somebody is currently looking into? I'm quite close to buying a new, bigger sdcard but my antennapod episodes directory is currently 20.6 GB in size and there are _alot of files in there that aren't even available for download any more.

Am I out of luck with this one or is there any chance this might be fixed in the near future?

mdirik commented 5 years ago

You should have no problem as long as the path to the sd card isn't changed. Note the label of your existing card and use the same label while formatting the new card then copy the files over.

On Sun, Jun 23, 2019, 21:31 Michael Hellwig notifications@github.com wrote:

is this something that somebody is currently looking into? I'm quite close to buying a new, bigger sdcard but my antennapod episodes directory is currently 20.6 GB in size and there are a_lot of files in there that aren't even available for download any more.

Am I out of luck with this one or is there any chance this might be fixed in the near future?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AntennaPod/AntennaPod/issues/1777?email_source=notifications&email_token=AANPN2ZNKV2YYD3UCWDSJLDP366QPA5CNFSM4B6H75NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYLEJOY#issuecomment-504775867, or mute the thread https://github.com/notifications/unsubscribe-auth/AANPN25HTDGSN3CJ34SGAPDP366QPANCNFSM4B6H75NA .

mhellwig commented 5 years ago

turns out that no, that doesn't fucking work. The new card contains all the files from the old card and it has the same label as the old one. Still, antennapod doesn't even see the directory. I start it and get the "no external storage available, please pick a storage location"-dialogue.

Is there any way to explicitly pick a new storage location that contains the same files and have antennapod accept those files? Because at least half of my podcast files (about 40 hours worth) CAN'T BE RE-DOWNLOADED! (German and Austrian public media, stuff is only online for 7 days because of stupid laws). And I can't find a way to make antennapod think it's the same card, even though you seem to think that's easy.

Note: in windows10 I can set the volume label when formatting an exfat card. that's an 8-digit number. So I can make that equal to the old card. BUT when looking at the mounted card on the phone in, say, Total Commander, there seems to be an additional, much longer number associated with the card as well, it's 32 digits long and there doesn't seem to be a way to change it.

mhellwig commented 5 years ago

OK, last post deleted. Turns out, mkexfatfs lies to you when creating a filesystem. It claims to set the volume ID to the value you give, but it doesn't actually do that. When I just tried doing that, the label was sufficiently similar that I didn't notice, but I just tried it again and it is actually different. So. I have Win10 Pro AND Linux available. How do I set the volume ID on an exFAT microSD card such that I can define the mountpoint under Android 8.x? Because the ID is what defines the mountpoint, not the label. Only if I can set that would the advise given by @mdirik above work.

EDIT: mkexfatfs doesn't lie, it does set the ID. Only the ID is not what is relevant here .. For more explanation see https://github.com/relan/exfat/issues/127

mhellwig commented 5 years ago

right. So. Apparently the thing that determines the actual mount-point ISN'T the filesystem ID. I had misunderstood, that's a 32-BIT ID, not a 32-digit hex ... BUT the mountpoint comes from some 32-digit hex-code (i.e. 128 bit). That points to the culprit being a GPT partition ID (because those are 128 bit). I'll see if I can edit that ..

RalfJung commented 5 years ago

@mhellwig I can recommend installing Voice. It's an audiobook player, but more importantly it can play files from a directory you point it at. You should be able to play your archived downloads with that. I have used it to listen to podcast files that were not available in RSS form. It also has some other feature that would be nice for AntennaPod, such as seeking back a bit when you pause.

mdirik commented 5 years ago

right. So. Apparently the thing that determines the actual mount-point ISN'T the filesystem ID. I had misunderstood, that's a 32-BIT ID, not a 32-digit hex ... BUT the mountpoint comes from some 32-digit hex-code (i.e. 128 bit). That points to the culprit being a GPT partition ID (because those are 128 bit). I'll see if I can edit that ..

I've switched to a new SD card today and I've used the same process I used the last time. I've set the volume id to be same as the previous one (it shows up as "Volume serial number" in dumpexfat output). It is set by the -i option of mkexfatfs. If you do not want to do a reformat there are Windows tools to change the serial number. You can also change it manually (see https://superuser.com/questions/1247972/change-uuid-of-vfat-partition for details. You need to use 100 as offset value for exfat instead of 67, and run exfatfsck afterwards).

I've done as above, switched the cards and the new SD card got mounted under the same mountpoint as the old one (/storage/). It is a transparent change as far as apps go. I wonder if you're having an issue with the Android variant you're using.

Anyway, if you still can't get it to mount in the same path, you can export the Antennapod database, change all the paths you want on your computer using something like SQLite editor and restore it back. This was an approach I've used previously while moving to a new phone. New phone was using a newer Android version which was mounting the same SD card at a different path.

Still it is very unfortunate Antennapod isn't using relative paths.

Good luck

numericOverflow commented 5 years ago

Hey @mdirik - I'm trying what you suggested to manually edit with offset=100 for exfat, but after changing the VolumeID and then running exfatfsck, I get an error: ERROR: Invalid VBR checksum 0xea89ed03 (expected 0xea842b03) at which point exfatfsck immediately exits, and I also can't mount the exfat partition any more. As soon as I restore the original VolumeID, the problem is gone and partition is mountable.

How did you get around the invalid checksum after editing VolumeID?

mdirik commented 5 years ago

Hey @mdirik - I'm trying what you suggested to manually edit with offset=100 for exfat, but after changing the VolumeID and then running exfatfsck, I get an error: ERROR: Invalid VBR checksum 0xea89ed03 (expected 0xea842b03) at which point exfatfsck immediately exits, and I also can't mount the exfat partition any more. As soon as I restore the original VolumeID, the problem is gone and partition is mountable.

How did you get around the invalid checksum after editing VolumeID?

exfatfsck offered to fix the checksum and I accepted. I didn't need to do anything else. (using exfatfsck 1.3.0). I used the same command from the superuser link above, except that I've used seek=100 instead of seek=67.

numericOverflow commented 5 years ago

exfatfsck offered to fix the checksum and I accepted. I didn't need to do anything else. (using exfatfsck 1.3.0). I used the same command from the superuser link above, except that I've used seek=100 instead of seek=67.

Interesting, my version of exfatfsck must be old since it just aborted instead of offering to fix the checksum.

It looks like exfatfsck v1.3.0 introduced the VBR checksum fix code

I was using a random old bootable linux USB stick I had sitting in a drawer which very likely predates the required version to fix the checksum. I'll try it with a recent linux build this weekend.

numericOverflow commented 5 years ago

FYI - @mdirik you were right, using exfatfsck v1.3.0 worked to fix the checksum after updating the VolumeID on my exfat partition. I have successfully renamed the new SDCard to seamlessly replace the old one in the eyes of my android phone. Thanks for the help!

antennapod-bot commented 2 months ago

This issue has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/new-sdcard-and-paths-change-workaround/5355/1

Krysztophe commented 2 months ago

I had the same problem. It's a shame that the paths are not relative.

The workaround works with an export, UPDATE and reimport of the DB (see https://forum.antennapod.org/t/new-sdcard-and-paths-change-workaround/5355)