make .torrent filename the same as original file
dingens opened this issue · comments
The filenames of torrent files bitlove is currently creating (${infohash}.torrent) are very unhandy. I think it would be great if they were the same as the original filename (with the extra .torrent extension of course).
There might be duplicate file problems, so the files should be placed in subdirectories (one for each podcast, for example /johndoe/my-podcast/my-podcast-001.torrent).
I'm sending a Content-Disposition header with the filename. Does that help?
It's just that duplicate content of different feeds should result in the same (info) hash. Perhaps we could redirect /johndoe/my-podcast/my-episode-001.torrent to /t/infohash.torrent?
Lastly, you can always extract the (original) filename from the .torrent itself. It's key name in key info.
No, you got me wrong :-)
What I mean is that I don't like the file having that cryptical name. I would like if it would be called my-podcast-001.mp3.torrent (more general: the original filename plus .torrent). That way you can immediately see what file a .torrent file belongs to.
So what I mean is: the .torrent file should not be named $infohash.torrent but $original_filename.torrent.
yes, that would definitely be better. see screenshot from within rssOwl: http://img196.imageshack.us/img196/7154/rssowlscreenshot.png
Would an enclosure/@title help in that case?
In my data model torrents don't have a fixed association to their origin but are globally identified by their info_hash, and my inner algorithmeer enjoys that fact too much to give it up without proper discussion.
Would an
enclosure/@titlehelp in that case?
I have no idea. :) Would that mean extra work for content creators to set it up?
Couldn't it have both? Prefix the title with an abbreviated hash (like git commits)? (see here on a short explanation on those)
Would an
enclosure/@titlehelp in that case?
I think, not. And it doesn't solve anything for the web interface.
In my data model torrents don't have a fixed association to their origin but are globally identified by their info_hash, and my inner algorithmeer enjoys that fact too much to give it up without proper discussion.
Hm. I think username/podcastname/filename isn't a too bad ID either, don't you think? Alternatively, I think a lookup to match from /t/username/podcastname/filename.torrent -> info_hash is not that expensive (However I don't know your database layout, of course).
If you don't see any "clean" way, at least a Content-Disposition header with the original filename+.torrent would be cool. That should help at least for those clients that interpret such a header (which at least includes common browsers, I assume),
Web interface users enjoy the all information of the Bitlove UI and Content-Disposition headers.
I think any change to enclosure paths needs to be strongly justified as it is going to be very inconvenient to feed subscribers.
Hm, I think you still understood something else than what I wanted to say ;) At least what you said does not make sense to me, so I assume you mean something else than i do. I'll try in German because I hope I can better express myself there (sorry).
Das Problem ist, dass die Torrent-Datei so einen kryptischen Namen hat. Es wäre also schön, wenn man (wie auch immer die Daten intern identifiziert werden) von außen einen „human-readable“ Dateinamen hätte. Es bietet sich an, einfach an den Original-Dateinamen .torrent ranzuhängen. D.h. meinpodcast-001-erste-episode.mp3.torrent statt 4fe5d8bb27bcdc1603.torrent.
Momentan werden die Torrent-Dateien ja von /t/4fe5d8bb27bcdc1603.torrent ausgeliefert, dh wenn man sie runterlädt, wenn man den Link anguckt, und im Feedreader wird dieser kryptische Name angezeigt. Der Wunsch wäre, dass die Torrent-Datei eben so heißt wie die Originaldatei.
Das gibt dann zwei Probleme:
- Eindeutigkeit, so ein Name könnte ja mehrfach auftauchen. Da wäre mein Vorschlag, die Dateien nicht von
/t/meinpodcast-001-erste-episode.mp3.torrentzu servieren, sondern von/t/benutzer/podcastname/meinpodcast-001-erste-episode.mp3.torrent(benutzer/podcastnamewäre zbmetaebene/cre). So hat man schonmal Kollisionen zwischen verschiedenen Feeds verhindert. Bleiben noch gleiche Dateinamen innerhalb eines Feeds, aber das sollte eigentlich nicht auftauchen, und wenn doch, ist es höchstwahrscheinlich ein Fehler. - Mapping von diesem schönen Pfad zum info_hash, den du ja intern verwendest. Ich hoffe, da fällt dir was ein :-)
- Probleme für Feed-Benutzer sehe ich da wirklich keine, im Gegenteil, es löst das Problem von screen123456s Screenshot oben.
So, ich hoffe, ich habe es jetzt gut rübergebracht :)
Ok, hier noch einmal meine Gegenfragen auf Deutsch:
- Wenn du einen .torrent im Browser herunterlädtst, wird ein ordentlicher Dateiname wie
meinpodcast-001-erste-episode.mp3aus demContent-Disposition-Header genommen. Klappt das für dich nicht? - Zeigt dein Feedreader es nicht an wenn im Feed
<enclosure title="Episode 23 (Ogg)"/>auftaucht?
Bei /t/benutzer/podcastname/meinpodcast-001-erste-episode.mp3.torrent würde ich sogar mitgehen.
Wenn du einen .torrent im Browser herunterlädtst, wird ein ordentlicher Dateiname wie
meinpodcast-001-erste-episode.mp3aus demContent-Disposition-Header genommen. Klappt das für dich nicht?
Oh, hups, doch, da hab ich wohl beim ersten Mal wget genommen und nicht genau genug hingeguckt. Sorry. Wenn es mit wget nicht perfekt funktioniert ist verschmerzbar ;)
Zeigt dein Feedreader es nicht an wenn im Feed
<enclosure title="Episode 23 (Ogg)"/>auftaucht?
Nö, also ich hab gerade http://bitlove.org/metaebene/not-safe-for-work/feed probiert, da wird im Firefox $infohash.torrent angezeigt, Liferea zeigt die ganze URL an.
Im RSS steht aber nur das hier:
<enclosure url="http://bitlove.org/t/6202788597ee43264e3d2d53b8b6166b2a92794e.torrent" length="61199274" type="application/x-bittorrent"/>
To be deployed soon.
Great! Thank you!