[gpodder] Re: gPodder 3.1.0 "The Discipline of D.E." released
- From: Bernd Schlapsi <brot@xxxxxxxx>
- To: gpodder@xxxxxxxxxxxxx
- Date: Sat, 09 Jun 2012 20:42:11 +0200
Hi,
Have you ever thought using github?
I applied your patch and get an error when I try to sync two episodes:
Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 504, in run
self.__target(*self.__args, **self.__kwargs)
File "./gpodder-dev/src/gpodder/gtkui/desktop/sync.py", line 162, in
sync_thread_func
device.add_sync_tasks(episodes, force_played=force_played)
File "./gpodder-dev/src/gpodder/sync.py", line 226, in add_sync_tasks
if self._config.device_sync.after_sync.delete_episodes and not
track.is_locked:
File "./gpodder-dev/src/gpodder/model.py", line 159, in _deprecated
raise Exception('Property is deprecated!')
Exception: Property is deprecated!
~ Bernd
On 2012-06-09 17:47, Joseph Wickremasinghe wrote:
> Hi Bernd,
>
> I'll let Thomas give you the official opinion but I would consider it in a
> mature beta phase right now. The code is on my local machine, but I've been
> sharing updates in the form of patches to the master (3.x) branch of gpodder.
> I would suggest downloading the patch from Bug 1579 and applying it against
> your code?
>
> https://bugs.gpodder.org/show_bug.cgi?id=1579
>
> Currently device sync is only implemented for a filesystem-based mp3 player
> since that's what I use.I have access to an iPod shuffle so I can add that in
> at a later date but I want to get filesystem-based sync completely finished
> up & integrated first.
>
>
> J.
> --- On Sat, 6/9/12, Bernd Schlapsi <brot@xxxxxxxx> wrote:
>
>> From: Bernd Schlapsi <brot@xxxxxxxx>
>> Subject: [gpodder] Re: gPodder 3.1.0 "The Discipline of D.E." released
>> To: gpodder@xxxxxxxxxxxxx
>> Date: Saturday, June 9, 2012, 3:22 AM
>> Hi Joseph,
>>
>> what is the current state of you synchronisation work?
>>
>> Do you work on your code local on your machine or could you
>> provide a
>> github repository with your own device-sync branch?
>> This would be great so it would be easy for everyone to test
>> and track
>> your progress :-)
>>
>> I would like to test the device-sync because I would like to
>> see this
>> feature in the 3.x version of gPodder in the near future.
>> At the moment I'm still using 2.x, but writing code for 3.x
>> which I'm
>> not able to use, because I need the device-sync.:-(
>>
>>
>> Thanks,
>> Bernd
>>
>>
>> On 2012-05-28 16:20, Thomas Perl wrote:
>>> Hi Joseph,
>>>
>>> (sorry for taking again very long to respond, but I
>> wanted to allocate
>>> enough time again to make sure I can review the patch
>> and give some
>>> feedback)
>>>
>>> 2012/5/20 Joseph Wickremasinghe <jnwickremasinghe@xxxxxxxxx>:
>>>> Thanks for your comments. After my last email, I
>> switched to a 'one task per episode' approach and made some
>> further progress. I'm including a patch to add device sync
>> to gpodder which uses the 'Downloads' tab to show progress.
>>> Thanks - this looks good. I've left some feedback on
>> the bug report
>>> where you submitted the patch.
>>>
>>>> The synchronization process opens the device and
>> creates a 'SyncTask' object for each episode synchronized.
>> The SyncTask object is derived from DownloadTask, overriding
>> the run() method. The task is then registered with the
>> download status model and added to the download queue, which
>> then executes it and updates the GUI in the same way as for
>> downloads.
>>> Yes, that sounds good and should work. For later (after
>> merging or
>>> just before), we should probably rename the classes and
>> the UI parts
>>> so that is clear to the user that the downloads tab is
>> also used for
>>> other progress information (and also in the code so
>> that developers
>>> reading the code can quickly find their way through the
>> codebase).
>>>> Please let me know your comments. :) There is
>> probably some code refactoring that could be done, perhaps a
>> reworking of the Device & SyncTask objects, too.
>> Presently the Device adds the Task objects to the queue, but
>> when the tasks are executed they call the add_track method
>> on the device to actually copy the files over. Probably not
>> the cleanest way to do it, but this is still a
>> work-in-progress :) This is currently only implemented for a
>> filesystem-based mp3 player.
>>> See the comments in the bug report. Please also tell me
>> if you'd
>>> rather like me to have a go through the patch and do
>> some clean-ups
>>> that I think are necessary (mostly just code style,
>> etc..) or if you
>>> would like to do this yourself (I'm happy with both
>> approaches, and
>>> don't want to annoy you with requests for reformatting
>> the code ;).
>>>> I can certainly work on making this an extension as
>> well, but it was easier for me to finalize the interface and
>> then figure out how to make it an extension.
>>> Yep, I guess the first step could be to integrate this,
>> and then
>>> re-work this as an extension. At this point, I'm quite
>> happy if we
>>> could get it in as such (for the Gtk UI only) and then
>> later work on
>>> refactoring it up to a point where it can be used by
>> the CLI UI as
>>> well (maybe even Web UI).
>>>
>>> Looking forward to your comments and the next patch!
>> Thanks for
>>> working on this, it's really appreciated :)
>>>
>>> Thanks,
>>> Thomas
>>
>>
Other related posts:
