1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
|
targets for 0.3.0:
device auto-detection
MSC, MTP and iPod plugins
basic transfer support
device manager (removes UI dependence on HAL)
targets for 0.3.1:
improvements to device panels and manager (see below)
transcode-on-transfer
rockbox and DAAP plugins
audioscrobbler support
file layout support
- useful for main as well, so worth implementing
- probably make it part of xl.collection.Library
future:
UPnP (client and server)
DAAP server
==========================================================================
devices we want to support: (see per-device section FMI)
ipods (via python-gpod)
mtp devices (via pymtp)
mass storage (no library needed)
rockbox devices (no library needed to treat as MSC device, for
full DB updating a lib will be needed, prelimiary python
code for such is on the rockbox wiki)
audio cds (no library needed to play, pycddb for metadata)
mp3 cds (no library needed)
SACDs?
audio dvds?
mp3 dvds? (do these even exist?)
DAAP shares (via python-daap and python-avahi)
UPnP shares? (via python-coherence?)
device recognition/persistence:
require user to explicitly connect to a devices until configured otherwise
in the device manager
- prefs option to autoconnect in future, per-device
- HAL's udis are perfect for recognizing repeat devices
- is there a non-HAL way to detect when new fses are mounted?
- best solution thus far: don't try to auto-detect, just poll
mtab and libmtp when the device manager is open and require
users to manually connect through the device manager
transfer&syncing:
drag and drop from collection to device or vv. should work perfectly
allow sending an enitre playlist to the device (from tab, playlist manager
or file). this should also ensure that all tracks in the playlist also
are transferred to the device
cover art should be synced if possible
possibly also support uploading lyrics, in various formats
calculate the space needed for the transfer before we begin, and tell the
user if there's not enough space to complete the operation
- offer possible ways of resolving the issue? eg remove old podcasts/
songs, reencode to a lower bitrate, etc?
- may be slightly overkill
allow transcoding on transfer
by default, transcode only if not in a supported format
also allow transcoding by bitrate thresholds (eg >128kbps)
- allow transcode of VBR mp3 to CBR option? may be difficult, but
could be quite useful for some cheap or old players.
- other thresholds? filesize, lossless, etc?
playlists:
subclass playlist manager or something else?
if done right we can also just subclass the ui's playlist manager to keep
everything really simple
podcasts:
????? (podcasts not yet implemented in trunk)
auto-delete old? (by date thresh? count thresh? played/not?)
should we download podcasts on sync if not downloaded, or skip
them until they are ready?
- if manual download, download on sync (but dont block other transfers)
- if auto download, prioritize in download queue
allow user to choose what podcasts to auto-sync
playing:
allow playing right off the device
dont use the stupid device URI schema introduced in 0.2. instead, just use
full filesystem paths and the COLLECTIONS set (with library path
regonition) to find where a track comes from.
- how to handle this with MTP as we cant actually play off the
device itself?
- uri rewriting may form a solution to this
hide tracks that are DRM-encrypted as we can't play them (can we recognize
this?) (could also be useful for main collection)
audioscrobbler:
Many players support logging tracks for submission to
audioscrobbler/last.fm
- file format: http://www.audioscrobbler.net/wiki/Portable_Player_Logging
- handle this in the audioscrobbler plugin as it's device-independant
display:
device manager:
show all configured devices, allow connection/disconnection
add dialog will show detected devices
- hal's storage.icon.[drive|volume] keys could be used for the icon column
also exposes any possible prefs for that device
path to music location (default: root/music)
path to podcast location (default: root/podcasts)
path to playlists location (default: root/playlists)
music subpaths (default: artist/album/num - title.ext)
supported file formats (default: from plugin)
playlist format to use (default: m3u)
transcode threshold (default: disabled)
transcode format(s) (default: from plugin)
name to use for the device (default: auto-detect)
whether to auto-connect when available (default: no)
- plugins can set which of these are visible and change the defaults
panel:
show remaining space at bottom of the panel
also show battery status if possible
Battery: xx%
Space used: xx%
- use mini progressbars instead/as well?
- show detailed info in tooltip
- charge ETA, xxGB of xxGB used
how should we expose playlists/podcasts?
0.2 method: they just appear as extra entries on top of the tree
pros: simple, easily seen
cons: inconsistent with main UI, interferes with using the tree,
doesn't handle podcasts
alternative: add a new combo box/tabs at the top to select the view
pros: simple, clean separation, easily extensible, allows reuse
of panel code from the rest of exaile
cons: less obvious, takes up some space
transfer queue:
show as simple button at bottom
[xx songs to transfer] [start]
clicking on the [xx ...] will open the list as a new tab in the
playlist area that can be edited
alternatively, the transfer queue could be exposed as another view
of the device panel as outlined above for playlists/podcasts
this is likely both cleaner and easier. in this case clicking
the [xx...] will switch to the queue view.
while transferring the progressbar will appear below all panels,
just as the rescan collection and other tasks do
info panel:
another entry in the drop-down with playlists/queue/etc, displays
stuff like device name, model, version, vendor name, device
type, detailed battery/space information.
- libmtp provides the following info:
device name
device serial number
manufacturer
battery level
model name
device version
free / total / used space
- HAL provides the following info:
info.vendor
info.product
storage.vendor - same as info.vendor, usually
storage.model
storage.size
storage.serial
- gpod provides nothing useful
- rockbox:
rockbox-info.txt
file panel? (was requested on forums)
per-device considerations:
mp3 players:
ipod:
supported formats: mp3, aac, alac
mtp:
supported formats: varies, usually mp3 and wma
mass:
supported formats: varies, usually mp3 and wma
rockbox:
supported formats: varies,
general: mp3, vorbis, mpc, ac3, aac, wma, speex,
wav, aiff, flac, alac, wavpack, shorten, monkey's,
sid, mod, nsf, spc, sap
ipod 1g-3g: same, but without ac3, nsf, sap
archos: mp3 only?
mp3 players are not auto-connected unless explicitly enabled in
that device's options.
optical media:
cds:
audio:
musicbrainz tag-finding support? (submission?)
can burning be sensibly exposed via the same transfer method?
CD-TEXT? (need a spec sheet for this and a sample disc/iso)
mp3:
how to distinguish from data cd
view as one large playlist by default, but allow a tree view
burning?
- as an extension to transcoding, allow auto-adjustment
of bitrate to provide the best quality that will fit
- warn if will go below threshold?
SACD:
need to get one for testing first
dvds:
audio:
need to get one for testing first
mp3:
do these exist? we can support them anyway I guess since they'd
essentially be mp3 cds with a different HAL signature and more
capacity
all optical media are auto-connected, track metadata is
loaded asynchronously
network:
daap:
python-daap is currently limited to version 6 of the protocol, is
there anything that supports 7?
- may not be feasable, as v7 uses certificate authentication
upnp:
python-coherence
- rhythmbox has a upnp plugin based on coherence we can use as
an example
network shares are never auto-connected
- device prefs will allow opt-in autoconnect
what this should all look like to the user:
cd (and similar) media:
user inserts disk
a new tab in exaile appears for the disk, automatically listing
all the tracks and retrieving metadata
devices (eg ipod):
user plugs in device
user opens the device manager, selects the device, and presses connect
a new tab appears with the name of the device. the track listing and
any other info is displayed
network shares:
user opens the device manager
detected shares are displayed along with other devices
user selects share to connect to and presses "Connect"
a new tab appears with the name of the share. the track listing and
any other info is displayed
manual:
user opens the device manager
user clicks "Add" button
user selects the type of device to connect to, a list of detected
devices is displayed, along with an option to manually specify
the device location
user selects a device/location and presses OK
a new tab appears with the name of the device. the track listing and
any other info is displayed.
rockbox:
detect whether rockbox is installed and adjust appropriately
- just treat this as another device class that overrides all others
- this won't handle dual-booting ipods nicely, but all other
players will be fine
- if rockbox's internal MSC support is enabled, we can use HAL flags
to tell that we're using rockbox. (ie. info.vendor == Rockbox)
update rb db in-place?
- incomplete DB format docs and preliminary python code are
available here:
http://www.rockbox.org/twiki/bin/view/Main/TagcacheDBFormat
allow updating rockbox firmware through exaile?
- would need auto-detection of device type
can probably be done via rockbox-info.txt
- save a backup of the old version and allow reversion to the backup
in the event something bad happens
- where should this be saved?
probably on the local computer rather than the device, as
rb is decently large (5-20 MB uncompressed)
- allow other items to be updated as well? fonts/etc?
- offering an exaile rockbox theme would be really cool
offer to install rb firmware for user if supported device is detected?
- we shouldn't do this as it requires root to install the bootloader
on most rockbox devices, but notifying the user that their
device is supported and linking them to install instructions
is feasible
option to strip "the" (or other words) from the beginning of tags on
transfer, as rockbox doesnt strip those itself yet
- may be a better idea to just work on supporting this in rockbox
itself instead.
covers:
rockbox doesnt (currently) like embedded covers, so we should
strip it from the tags on transfer
use ./albumname.bmp (rockbox only supports bmp, not jpeg or png)
in 3.1 and later rockbox supports scaling the artwork, so we should
just pick the biggest image we have on hand for the album and
use that.
- allow user to limit size of image to avoid excessive
disk/cpu use in rockbox?
DB auto-update should not be enabled at the same time as our DB updater, so
as to avoid duplicate work on the device. There are two ways to handle
this:
- dont update the DB if auto-update is set
- turn off auto-update when updating the DB
perhaps the best way is to simply ask the user which they prefer on
the first transfer if auto-update is enabled. rockbox doesnt
auto-update the DB by default, so most users wouldnt see it and
we can handle it silently.
- alternatively, just show a warning to the user
about it. clicking the warning would show additional
information and show how to disable it.
|