astro/prittorrent

BitTorrent Content Distribution for Podcasts

PritTorrent

Build

rebar get-deps compile generate

TODO

• URL longener?

• Fix empty downloads.type

• filter.js:

  • Fix button style breakage in Mozilla
  • Fix z-index (Android?)

• New {feeds,downloads}.{lang,summary,type} in:

  • Downloads Feeds
  • HTML

• enforce https for log in

• clickable stats hint

• <atom:link rel="self">

• <atom:link rel="alternate">

• stop seeding

• Check U-A & replace RSS links with Miro subscribe URLs

• Edit user:

  • About field

• Edit feeds:

  • Add & fetch immediately

• feeds_parse: http://video.search.yahoo.com/mrss

• more configurability

• Fetch & display feed summaries

• Feed summaries: X items, Y torrents

• Storage app

  • Avoid dup connections to 1 HTTP server (IP)
  • Fair queueing
  • Caching

• OEmbed

• Stats:

  • DLs by country/client?

• Rehash on detected enclosure data change

• Multiple sources per feed

Future features:

• UDP tracker
• UTP wire protocol
• UI: Wholesome OPML export
• Super-seeding
• Slot queues
• PEX
• DHT support

prittorrent's Issues

Magnet Links

Open Questions

Implement Extension for Peers to Send Metadata Files

See BEP 9

Display in UI

A small magnet aside the Download button?

Mandatory support for DHT?

Users may discard the HTTP tracker URL, making it necessary to actively publish the prittorrent seeder's address. Unfortunately, regular announces for a lot of Torrents incur increasing DHT traffic.

Two possible options:

• Traffic optionally paid by podcasters?
• Have someone sponsor a server with an UDP traffic flat-rate :-)

Please raise your voice if you have doubts regarding to what this will do to the global BitTorrent DHT.

Support for Permanent Redirects for Media File Enclosures

Bitlove currently does not properly handle links to media files that get redirected on temporary or permanent basis.

When reading a enclosure url from a feed, Bitlove needs to follow all redirects. While temporary redirects are just followed, permanent redirects should also change the URL Bitlove stores internally and that gets searched for when an application uses the API to request if a certain media file has been processed by Bitlove.

This behaviour solves various problems related to proxy systems like FeedBurner or other podcast statistics engines that a podcast feed might use.

Zusätzliches Trackermodul

Zusätzlich zum Seeder sollte prittorrent auch einen einfachen Tracker bereitstellen, der optional mitgestartet wird (Portnummer konfigurierbar). Welche Dateien über den Tracker angeboten werden ergibt sich wie für das Seeding aus dem seed file.

Der Tracker sollte alle möglichen Events loggen können. Am wichtigsten ist dabei das Download Event, bei dem der User-Agent, die IP-Adresse und der entsprechende Hash bzw. die zugehörige Torrentdatei im Logfile weggeschrieben werden sollten. Das Schreiben der IP-Adresse sollte dabei optional sein (default: off).

Das Logfile-Format sollte sich dabei an das Common Log Format vom Apache orientieren

Fehlerhafte enclosure-URL

Hi,

habe gerade festgestellt, das einige enclosur-Tags scheinbar eine fehlerhafte URL enthalten.

Bsp:

http://bitlove.org/hoersuppe/vorcast/feed/

"[...]

«enclosure url="http://podcast.hoersuppe.de/hs-079-250512.mp3" length="5272879" type="application/x-bittorrent"/»

[...]"

Ich bin mir nicht sicher warum, aber manchmal entscheidet sich mein uTorrent dazu, die mp3 runterzuladen und gibt dann die Fehlermeldung aus, dass der Torrent falsch codiert ist.

Gruß,
Henning

API / gpodder.net Integration

It would be great if there would be an API so that bitlove can be integrated in other applications / webservices. For my use case I would need an endpoint to retrieve torrent links (and bitlove URLs) for a given podcast feed URL.

I'd imagine something like

  GET /api/feed?url=http%3A%2F%2Fexample.com%2Fmypodcast.rss

  {
      "web": "http://bitlove.org/example/mypodcast",
      "feed": "http://bitlove.org/example/mypodcast/feed",
      "episodes": [
          {
            "web": "http://bitlove.org/example/mypodcast#directlink",
            "file": "http://example.com/mypodcast/episode1.mp3",
            "bittorrent": "http://bitlove.org/t/....e6ab17c48.torrent",
            "size": "5456546",
            ... more meta data
          }
       ]
  }

The additional meta data could be the number of completed downloads, number of seeders / leechers, current bandwith, Flattr links, etc, whatever you like to provide.

Auto-Reload der Seed Files geht nicht

Derzeit lies prittorrent die Seedfiles nicht wieder ein, wenn sie sich verändert haben. Auch nach Tagen sind Änderungen noch nicht übernommen und neue Dateien werden nicht geseeded.

include all entries in feed

Many podcasts have other entries in their feed than only "new episode" posts. To be able to fully replace the original feed with the bitlove feed, it is required that the latter also includes those.

I don't know about the web interface, maybe it would be nice to have that entry, too, at least in the /user/podcast view.

Use separate domain for feed URLs

Feed URLs and the UI URLs should be decoupled, to free the user interface from restrictions and allow future changes.

Currently, both the UI and feeds are served via bitlove.org. Instead, feeds should be moved to the subdomain feeds.bitlove.org.

This can be achieved by issuing by changing the feed URL in the UI and apply a Permanent Redirect when the old URL is accessed by applications. After some time, most if not all clients should have accepted the new URL as most clients do understand the concept. Those who don't should get a bug report and take a class in web protocols.

Example:

A feed currently residing under

http://bitlove.org/metaebene/cre/feed

should be redirected to

http://feeds.bitlove.org/metaebene/cre

Resizing Icons

If you zoom in, the Icon's should be scaled as well. Maybe require an icon of a certain size?

CRE100a Torrent wird nicht vermittelt

http://chaosradio.ccc.de/archive/chaosradio_express_100a.mp3.torrent wird offensichtlich nicht geseedet, während andere wie zb. http://chaosradio.ccc.de/archive/chaosradio_express_100.mp3.torrent sehr wohl vom Tracker vermittelt und auch vom prittorrent geseedet werden. Ursache unklar. Die Datei ist wie alle anderen auch im seeder file vermerkt.

Logile über syslog erzeugen

Der Server sollte ein Logfile via syslog erzeugen. Folgende Dinge sollten geloggt werden

• Start des Servers (mit Port-Nummer, Pfad Seed File)
• Beenden des Servers (Shutdown on SIGTERM)
• Beginn des Lesens des Seed Files
• Erfolgreiches Lesen/Fehler beim Lesen des Seed Files
• Nicht gefundene Torrentdatei
• Nicht gefundenes Verzeichnis
• Nicht gefundene Datei in , die von einem referenziert wird
• Erfolgreicher Beginn des Seedens eines Torrents (mit Hashvalue)

feeds.etag = NULL always

Kinda bummer for the recheck feature.

make .torrent filename the same as original file

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

Allow Feed Groups

Multiple Feeds should be able to be grouped under a single name. The UI could be extended in such a way that a podcaster can either create a new feed with Bitlove as before or create a feed group instead.

A feed group then gets multiple feeds assigned with one of them being the "default" feed. Each feed gets a separate slug that gets added to the feed groups slug, separated by "/".

Example:

User: metaebene
Group Slug: cre
Feed Slugs: m4a mp3 oga opus
Default Feed: m4a

Resulting Feed URLs:

http://feeds.bitlove.org/metaebene/cre/m4a
http://feeds.bitlove.org/metaebene/cre/mp3
http://feeds.bitlove.org/metaebene/cre/oga
http://feeds.bitlove.org/metaebene/cre/opus

Resulting Feed Group URL:

http://feeds.bitlove.org/metaebene/cre

When accessing the Feed Group URL, the system issues a Temporary Redirect (HTTP 1.1 Status Code 307, HTTP 1.0 Status Code 302) to point to the feed URL that is marked being the default, in this case:

http://feeds.bitlove.org/metaebene/cre/m4a

Feed Groups are presented as such in the User Interface so that users see that what kind of feeds are available and can choose to select the default feed or a specific feed.

RSS Feed Miro Problem

Ich benütze Miro 4.0.6 und am 14.06.12 wurde die kanpp 20 folgen von CRE (http://bitlove.org/metaebene/cre/feed) ungefähr 5 folgen von NSFW (http://bitlove.org/metaebene/not-safe-for-work/feed) sowie mehrer folgen Chaosradio (http://bitlove.org/cccb/chaosradio/feed) als neu verfügbar angezeigt. Bei Chaosradio kann ich noch genau sagen welche folgen das sind: und zwar alle Folgen vor CR 156 die im aktuellen Feed angezeigt werden. Ich vermute das hat irgendwas mit dem einlesen ältere folgen zu tun welche dann Miro als neu, (da sie noch nicht im feed waren) interpretiert. Da pro feed nur max 3 neue folgen geladen werden (Standardt einstellungen von Miro) ist das jetzt nicht all zu schlimm für mich, ich muss nur die feeds auf "keine neuen folgen herunterladen" ändern und die 3 folgen löschen. Jedoch weis ich nicht ob es nicht eine möglichkeit geben müsste das miro nicht denk es handle sich um neue Folgen.

Edit: Das problem scheinen vermutlich noch etwas mehr personen zu haben siehe dazu die Mainpage von heute Morgen (http://yfrog.com/obsmzcp) bzw Downloadstatistik der CRE folge von heute (http://yfrog.com/khjkdlp)

Support BEP0019: WebSeed - HTTP/FTP Seeding (GetRight style)

Muß natürlich auch in den .torrent-Files stehen, dann können aber auch normale Clients auf HTTP zurückgreifen.

Podlove integration still not working?

As can be seen at https://sendegate.de/t/podlove-und-bitlove-integration/921/3 (german) the seamless integration of bitlove torrents into Podlove-Publisher doesn't seem to work for at least many users.
Is there any hope that can be fixed? If not, maybe http://bitlove.org/help/podcaster/widget could be updated correspondingly to prevent further irritations.

About this: Is there a rule how often bitlove is looking up the feeds? Is a period about 12 hours without updating the feed after an episode release normal?

Thx for support and regards,
Homer

Name des Podcasts als Tag in den RSS/Atom Feed

Es wäre super, wenn der Name des Podcasts und vielleicht auch der Name des Users, dem der Podcast gehört, im Feed auftauchen würden. Entweder als Text oder optimalerweise als Tag.
Aktuell sehe ich nur einen Titel z.B. "Folge 540: Theatrhythm Final Fantasy" oder "014 Interview Sts Vera Reiß" und dazu eine .torrent als Attachement.

Mit dem Namen des Podcasters und/oder des Podcasts ließe sich der Feed im Reader einfacher Filtern.

All configuration from an XML file

With all includes and app parameters.

Make Flattr-Button for Bitlove project more prominent

It took me a really long time to find the flattr button to support the bitlove project. They are currently hidden in the displayed torrent files. I recommend to create a single flattr button for the project and place it in the footer or alternativly in the header - easy to find and easy to click.

All Feeds Page

Create a page that shows all available podcasts torrent feeds - recent and popular listings may not contain all available podcasts and in this case it will be hard to find the correct url to the missing podcast feed.

Support custom enclosure guid element to reference media files

This is an alternate solution to #30

If Bitlove would accept a custom Bitlove enclosure-guid element in a feed, any bitlove-aware feed publishing system could reference media files in Bitlove using a self-chosen GUID.

Example:

<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:bitlove="http://bitlove.org" version="2.0">
<channel>

    <item>
        <title>Podcast Episode</title>
        <enclosure url="http://example.com/podlove/file/2342/" length="36557482" type="audio/mp4" />
        <bitlove:enclosure-guid>http://example.com/podlove/file/2342/</bitlove:enclosure-guid>
    </item>

</channel>

The Bitlove Widget could accept the GUID as a valid URL in the torrentByEnclosure JavaScript function and we're set.

Schnupper-Feed

Ich kann kein Stück Erlang, daher kann ich keinen Pullrequest erstellen, aber hier ein Feature Request

Es wäre interessant einen Feed zu haben, in dem zufällig (oder auch nicht) eine Mischung der auf dem Tracker verfügbaren Podcasts angeboten werden.

Zwei Überlegungen stehen dahinter:

• Für die Hörer/Konsumenten gibt es die Möglichkeit zufällig für sie neue Podcasts kennen zu lernen, gefällt es können sie den entsprechenden Feed abonieren ansonsten einfach skip
• Für den Tracker und die Caster entsteht der Vorteil, dass für diese Episoden zusätzliche Seeder entstehen, selbst wenn sie es nicht sehen oder hören, so verteilen sie die Datei ja vermutlich. Dies entlastet den Web-Seed.

Die Auswahl und Frequenz der jeweiligen Episoden kann man manigfaltig organisieren, für die Häufigkeit böte sich eine Regel an wie "ca. 10% aller eingereichten Episoden höchstens jedoch eine täglich". Für die Auswahl sollte man einerseits neu hinzu genommene Podcasts hinein nehmen, aber auch die Podcaster sich dies wünschen lassen (dafür kann man ja irgendein Feld im Zuliefer-Feed erdenken) von einer Episoder von der sie glauben, dass sie besonders für Neueinsteiger geeignet sind um den Cast kennen zu lernen (irgendeine Art Missbrauchsfilter, damit nicht täglich der gleiche Podcast auf diesem Schnupper-Feed liegt erscheint sinnvoll).
Verbleibende "Kapazität" könnte man - mehr oder minder - zufällig auffüllen.

Control Tool

Der Server sollte sich über ein separates Tool (dabei kann es sich auch um ein einfaches Startup-Script handeln) starten, neustarten und beenden lassen.

$ prittorrentctrl start/restart/shutdown

RSS-Feed nicht aktuell

Der Feed unter https://bitlove.org/holgi/wrint/feed hinkt deutlich hinterher. Unter https://bitlove.org/holgi/wrint gibt es WR068 schon im Feed noch nicht.

P.S.: Ich hoffe mal ich bin hier nicht falsch, und prittorrent enthält auch das Webinterface von bitlove.org?

integer_to_string/2 undefined

Hello,
when I try to compile prittorrent this error occurs:

~/prittorrent# rebar get-deps compile generate
==> cowboy (get-deps)
==> epgsql (get-deps)
==> lhttpc (get-deps)
==> rfc4627_jsonrpc (get-deps)
==> poolboy (get-deps)
==> exmpp (get-deps)
==> gen_smtp (get-deps)
==> shared (get-deps)
==> model (get-deps)
==> ui (get-deps)
==> feeds (get-deps)
==> hasher (get-deps)
==> seeder (get-deps)
==> ui (get-deps)
==> feeds (get-deps)
==> hasher (get-deps)
==> seeder (get-deps)
==> prittorrent (get-deps)
==> cowboy (compile)
/root/prittorrent/deps/cowboy/src/cowboy_http_static.erl:468: function integer_to_list/2 undefined
ERROR: compile failed while processing /root/prittorrent/deps/cowboy: rebar_abort

I've tried it on a debian vps

Source Dateien mit Prüfsummen aus Torrent-Datei vergleichen

Der Server sollte optional Chunks aus Sourcedateien mit den Prüfsummen aus der Torrent-Datei überprüfen, um fehlerhafte Dateien zu erkennen. Wenn Chunks fehlerhaft sind oder nicht existieren (Datei zu klein), sollte dies im Log angezeigt werden und keine Dateien an Clients ausgelagert werden.

Support für mehrere Seed Files

PritTorrent sollte per Konfigurationsdatei oder Kommandozeile auch mehrere Seed-Files akzeptieren, damit sich unterschiedliche Bereiche des Servers mit separaten Konfigurationsdateien beschrieben werden können. Der Inhalt aller Dateien sollte wie der Inhalt einer Datei behandelt werden.

Remove disconnected peers from peerdb

To allow later reconnect by tracker result

Support for Paged Feeds

When reading podcast feeds, please support Paged Feeds based on RFC 5005 as summarized here:

http://podlove.org/paged-feeds

Basically, feeds get extended by a set of multiple feeds interlinked via <atom:link rel="next" href="{next-feed-url}"> elements. The parser should read all linked feeds in order and treat it as one big feed.

On the output side, Bitlove should also use paged feeds and split the pages at the same number of episodes as the original feed.

Alternatively, the BitTorrent feed should put all episodes in one feed although this might create really huge feeds.