Apologies if this has already been answered... I did search but couldn't find my same problem.
I have an issue where any video podcasts are being deleted whenever I reboot my phone.
For example, I am subscribed to the MSNBC Countdown video podcast. I let DoggCatcher automatically download a video, and it shows up in "/sdcard/DoggCatcher/EpisodeEnclosures/12".
However, I then reboot my phone, and the file is gone.
I would think that this is a problem with my phone or my SDCard, but like I said... this only happens with video podcasts.
I haven't really tried any troubleshooting yet (uninstalling/reinstalling, etc.), I thought I'd ask for ideas first.
Thanks in advance!
-Charlie
I forgot to mention...
If I restart the phone while a download is in progress, the partial download is still in the phone after I restart. So it's only complete videos that disappear.
I see the same thing.
The relevant settings I have are:
- delete all done items
- prompt after video is done playing
- do not start DC on reboot
- refresh interval is set to never
Thanks for letting me know.
Last I heard, Pete was on cyanogen.
Are you also running a custom rom?
I can't seem to make this problem occur.
Do I understand correctly that the videos are on the phone, then you reboot, and before DC is started, the vids are gone? That sounds like it matches pete's description but I'm not sure about PLuGGPro.
Also, I changed ROMs a couple of days ago to the stock TMO OTA w/root, and the problem still occurs. Here's the sequence:
I happened to have an HD Nation vidcast in DC just now, so I rebooted and re-started DC as a test. After the restart, the feed list showed that I had the one video for HD Nation, but when I ran the update it added the same episode to the queue for download. (My feed is set up for one item, and one media enclosure)
I did not go into the HD Nation feed to see if DC reported that the file was there prior to running the update, so I redownloaded HD Nation and rebooted again. Again, the feed list indicated 1 item, but when I went into the HD Nation feed it showed Not Downloaded.
I'll dig a little deeper...I created a mantis issue for this.
http://mantis.snoggdoggler.com/view.php?id=227
I realize that the core cause of this is an Android bug, but isn't there anything that can be done to compensate for it?
What is creating the .nomedia file in the first place?
Why can't you have DoggCatcher delete any .nomedia files as a regular maintenance operation in folders that it believes has podcasts in them?
Why does this only happen to DoggCatcher video podcasts, and not audio ones, or any other media on my phone, for that matter?
DC is creating the .nomedia files to hide the media from the android gallery. If you don't mind having all your media show up in the gallery then you can disable that DC preference...it is either very close or at the bottom of the preferences, something like 'show media in android'.
There are details on this preference here - http://www.snoggdoggler.com/node/277
Am I out of my mind, or does mediascanner just look at file extensions? Would a cheap 'n dirty fix just be to have DC rename video files on download, and rename them back when launching the player?
I'm not sure that's the case, it may be possible but I can't say positively. DC is pretty dependent in a few places on the extension, more that just launching the player, so while it's possible to do what you are saying, it's not going to be trivial. I would be concerned that while attempting to work around one problem, I could create another more serious problem since file naming logic is pretty critical to a lot of operations in DC.
I would be interested to hear if this has been fixed in 1.6, or 2.0...or more importantly if it has a registered bug in android at all. It would seem best to go after the root cause.
In the mean time, we can toggle the media scan preference.
I get what your saying. To be honest, I wouldn't mind letting the phone index the videos, it's the audio podcasts that drive me nuts.
I realize that separate toggles for indexing audio and video would be likely be impractical due to how DC organizes media and feeds. Would the ability to override the indexing default on a feed-by-feed basis be possible? A feature like that would probably be useful for people who (unlike me) listen to both talk-show style and music podcasts.
That'll work.
I created an issue for this.
http://mantis.snoggdoggler.com/view.php?id=320
If you enabled the "Hide media", this creates a .nomedia file in each folder. I had problem with video files in the same folder as this .nomedia file gets deleted on reboot, even if it's files not from Doggcatcher, on some ROMs...
So I thinks it's ROM problem and not a Doggcatcher problem...
I think you can use a .folder file or something that will do the same and maybe the vids won't get deleted...
BTW, count me in for Beta testing please.
I tested this tonight... (I'm using TheOfficial TMO OTA Base ROM without the expansion pack)
First, I downloaded a new video item and then rebooted. The item was gone.
Then, I redownloaded the item, and deleted the .nomedia file in the enclosure directory. In my case, that was folder 10. I rebooted and the item was gone again.
Then, I redownloaded the item, and deleted the .nomedia file in the DoggCatcher folder. I rebooted and the file was still there!
Then, I ran a full Feed Update (previously I was just tapping on the item within the particular feed to redownload), and checked the folders. The .nomedia file was not in the DoggCatcher folder, but it was back in the 10 folder. Unfortunately, after I rebooted again, the item was gone.
So, even with this fix, DoggCatcher will unfix it whenever you update all your feeds at once.
Good thing you can confirm what I said.
Now, developper can try and use .folder (?) instead of .nomedia... But I dont really know about this one
Looks like this is an Android issue
http://code.google.com/p/android/issues/detail?id=3692
So what is creating the .nomedia file? Perhaps Doggcatcher should make sure that any .nomedia files are deleted whenever it saves a download to a directory.
Also, I am using the official TMO 1.6 update.
That's a preference in DC, way down at the bottom. I think it's called Enable Media Scan. I have that unchecked, because I don't want the enclosures showing up in the music player. It would appear that every time a full update is performed, DC will place .nomedia files in the individual enclosure directories.
You beat me to the response and thanks for doing all the testing and finding the link to the mediascanner defect.
I had looked through the code and just couldn't see how DC was deleted those files.
As you say, what DC does is place the .nomedia files in the directories containing media. This tells the mediascanner to ignore the directories. The preference in DC "Enable media scan" is enabled by default...and this will create the .nomedia files on an update. If you disable the preference, the .nomedia files will be removed on the next update.
What's interesting to me is that you guys only reported the problem when the phone reboots, and the mediascanner defect indicates that it would occur whenever the scanner scans. I've heard that the mediascanner also scans when the sd card is mounted, so I would expect the media to be deleted when the card is mounted.
Being an victim of this issue, I've been doing a lot of research on it.
I did some testing today after having looked at the media scan code that everyone seems to think is the culprit. To my surprise I didn't see anything there that would cause files to be deleted, let alone selectively singling out specific file types.
http://www.netmite.com/android/mydroid/external/opencore/android/mediasc...
This got me to thinking so I ran some more tests. I made a directory off the root of my SD card called "test" and put a ".nomedia" file in it. Then I copied a few ".mp4" files from one of the feeds in my "DoggCatcher/EpisodeEnclosures" directory.
I mounted and unmounted the SD card a few times and not only did the files in "test" NOT disappear, but they were properly excluded from the native music and video directories. I think this shows that using the ".nomedia" file is not directly the cause of the files getting deleted.
Finally, I copied the ".nomedia" file over to the enclosure directory where the videos I was testing with came from. I did this from inside the phone using a file manager. The DoggCatcher process was active in the background but not playing any files at the time. When I switched back to DoggCatcher the ".mp4" files were gone. Switching back to the file manager verified this. This happened without unmounting the SD card.
I cleared the all files in the enclosure directory (which was just the ".nomedia" file at this point) and copied the video files I had used for testing back into the enclosure directory. After verifying DoggCatcher saw the enclosure files and that all feeds were updated I repeated the test. Dropped ".nomedia" into the enclosure directory and shortly afterward the videos disappeared.
I hope this helps find the source of the problem. Having a lot of feeds I follow it's imperative that I get them excluded from my media managers as it's making it very difficult to find regular media among all the podcasts.
That's good information, thanks for taking the time to collect it.
One thing to keep in mind and I'm pretty sure this is the case given the api to call the mediascanner...and that is that it is asynchronous and I would imagine that it runs with a low priority. So a scan that gets triggered may not have an immediate effect.
Also, DC only ever deletes files during an update, and possibly when an item gets completed.
I think at this point what I need to do is to add some logging to the one place in DC where media files are deleted. This way, we'll know for sure whether we should be looking at DC as the culprit or elsewhere. It probably not a bad idea to have that logging anyways.
I created an issue for this.
http://mantis.snoggdoggler.com/view.php?id=351
No problem. DC is great and I'm glad to be of some help. Still odd to me how the media type seems to be playing into the equation. I'm not only looking forward to the solution but I'm also dieing to find out what's wrong.
I had something similar but different happen to me the other day that I though might be helpful. I accidentally left DC active in the foreground (though not actually playing a file) while I mounted the SD card to access some unrelated files. DC didn't crash or complain when this happened. When I unmounted the SD card, all my downloaded enclosures except those that were listed as partially played were deleted.
Might not be related but I figured it was worth mentioning.
FYI... I am getting the exact same symptoms.
I run a Sprint HTC Hero with default ROM and no root. I recently enabled the hide media from android feature.
The biggest reason for this has to do with the directory naming convention. It fills my media player with folders that are just numbers. If the folder names were more human readable I think I wouldn't even need this feature.