Bug 864 – Autosync device when connected

gPodder Bug Tracker – Bug 864

Autosync device when connected

Last modified: 2012-10-13 16:30:26 BST

DE
| EN
| FR

This bug tracker should not be used to create new bug or feature requests. Please use the new issue tracker on GitHub.

Bug 864 - Autosync device when connected


Summary:	Autosync device when connected

Status:	UNCONFIRMED

Product:	gPodder
Classification:	Unclassified
Component:	Portable device synchronization
Version:	unspecified
Hardware:	PC Linux

Importance:	low feature request
Target Milestone:	---
Assigned To:	Thomas Perl

URL:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2010-02-12 14:02 GMT by Maxim Prohorov
Modified:	2012-10-13 16:30 BST (History)
CC List:	4 users (show)

Attachments
Additional dbus methods&signals (7.17 KB, patch) 2010-08-31 21:32 BST, Maxim Prohorov	Details \| Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Maxim Prohorov 2010-02-12 14:02:16 GMT

While gPodder mostly automates fetching and keeping podcasts, it doesn't allow no-brain delivery of them (like iTunes :)

So, it would be nice to have:
 - Watcher of Hal/Devkit dbus calls.
 - Some pre/post-sync actions (To be aware of no-automount enviroment, some deletions/additions defined by user)
i.e. like it already does with cmd_download_complete

Comment 1 threexk 2010-02-25 21:20:32 GMT

Also interested in this feature.  It would be nice if you could configure things so you could just hook up your device and downloaded podcasts are immediately synced to it.  Or, if your device was already connected, as soon as a download completes, the podcasts are immediately synced.

I assume this is the same thing Maxim is talking about.  (I've never used iTunes.)

Comment 2 Thomas Perl 2010-02-28 12:57:36 GMT

I think the most sane (and extensible) way would be to provide a dbus function in gPodder that simply starts the sync process, and a dbus signal that gets sent by gPodder when the sync has been completed.

This way, such a "autosync" utility/daemon can be implemented by any of you (and heavily customizable), and it would work nicely with all the requested features (including mounting before sync and unmounting/ejecting after sync).

Comment 3 Amiad 2010-08-29 09:47:19 BST

I will very happy if this feature will add to gPodder.
manual sync is unnecessary work.

Comment 4 Maxim Prohorov 2010-08-31 21:32:50 BST

Created attachment 567 [details]
Additional dbus methods&signals

(In reply to comment #2)
> I think the most sane (and extensible) way would be to provide a dbus function
> in gPodder that simply starts the sync process, and a dbus signal that gets
> sent by gPodder when the sync has been completed.
> 
> This way, such a "autosync" utility/daemon can be implemented by any of you
> (and heavily customizable), and it would work nicely with all the requested
> features (including mounting before sync and unmounting/ejecting after sync).

(Almost forgot about this bug entry)
Draft of what this would be like from gPodder's side.
The only real problem (sort of) is that sync-ui window shows up. Possibly it's good idea to split things a bit, and implement syncing process more or less self-sufficient. But this could be emulated with api.py call.

Comment 5 Thomas Perl 2012-10-13 16:30:26 BST

Maxim: Can you update the proposed patch for gPodder 3?

exchange spam filter