search

astro / prittorrent

BitTorrent Content Distribution for Podcasts
http://bitlove.org/
93 stars 19 forks source link

make .torrent filename the same as original file #13

Closed dingens closed 12 years ago

dingens commented 12 years ago

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).

astro commented 12 years ago

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.

dingens commented 12 years ago

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.

screen12345 commented 12 years ago

yes, that would definitely be better. see screenshot from within rssOwl: http://img196.imageshack.us/img196/7154/rssowlscreenshot.png

astro commented 12 years ago

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.

screen12345 commented 12 years ago

Would an enclosure/@title help 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)

dingens commented 12 years ago

Would an enclosure/@title help 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),

astro commented 12 years ago

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.

dingens commented 12 years ago

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:

So, ich hoffe, ich habe es jetzt gut rübergebracht :)

astro commented 12 years ago

Ok, hier noch einmal meine Gegenfragen auf Deutsch:

Bei /t/benutzer/podcastname/meinpodcast-001-erste-episode.mp3.torrent würde ich sogar mitgehen.

dingens commented 12 years ago

Wenn du einen .torrent im Browser herunterlädtst, wird ein ordentlicher Dateiname wie meinpodcast-001-erste-episode.mp3 aus dem Content-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"/>

astro commented 12 years ago

To be deployed soon.

dingens commented 12 years ago

Great! Thank you!