Tribler V4.2 TODO


  • Let all code use Tribler.Core.API as sole import.
  • Migrate to using Core:
  • Check current usages of Session already added.
  • Replace all actionhandler references.
  • When adding torrents via a RSS subscription the TorrentSource id2src in the DB is not updated. When using RSS a new TorrentSource record is created, apparently the self.id2src is not updated as well.
  • Reimplement search without torrentManager / peerManager
  • Click on peer to get details gives error: adjust code to set Similar files / other files to new DB.
  • Reimplement logic behind Download booster and Play ASAP buttons


Low Priority

  • Reimplement selected_files with existing 'priority' field
  • *Config: some values will be runtime modifiable, others may be as well but hard to implement, e.g. destdir or VOD.

SOL: We throw exceptions when it is not runtime modifiable, and document for each method which currently is. TODO: determine which and document.

  • Test VOD quick startup with multi-file torrent. PiecePicker.am_I_complete is about whole file. This causes complete files in multi-file torrents to be played via HTTP instead of from file. Thus .movs won't play at all.


  • VOD: Check why prebuf pieces not obtained and implement rerequest of pieces if needed.

See PiecePickerVOD: self.outstanding, need to tweak further, especially for "wild" torrents (i.e., not supported by publisher via seeders)

  • Determine what are fatal errors for a tracker and move to DLSTATUS_STOPPED_ON_ERROR if they occur. Currently all tracker errors are put in log messages, and the download does not change status.


  • Write unit tests for API

TODO. Arno: Pioneer may do this as part of standardization effort.

  • Allow VOD when first part of file hashchecked? For faster start of playback


  • Adjust VideoOnDemand, such that when the download speed is < bitrate, but a large part of the video is already in, i.e. prebuffer+20 secs (or even just the 20 sec prebuffer) that it already starts to play, hoping we'll catch up the bitrate in that period.


  • Allow user seeking: i.e., allow user to set hi/mid/low priority set to some point in the future.


  • SwarmPlayer's VideoPlayer still reads old config to determine int/ext player. I modified it, but it needs to be cleaned up.
  • Search for TEMPARNO tags to see if stuff needs fixing.

Arno: mostly done. See VideoPlayer about EXTENSIONS

  • Replace ffmpeg.exe and VLC with newer version

  • Implement the HTTP seeding variant that does not require server-support (GetRight style)


  • Get rid off torrentManager and peerManager, such that there is no large-scale in-memory caching.

Remote query to 4.1. works, and starting a download from a remote hit. Also 4.2. returns hits to 4.1 using SQLite.

  • Document all *DBHandler classes' methods.
  • Get rid of MyPermID, MyIP and MyPeerInfo from SQLite MyDBHandler

Also: why is there an index on MyInfo, if it just contains 1 entry.

  • Install pysqlite2 / switch to Python 2.5 <-- Good idea to do now. Switch to latest M2Crypto, OpenSSL, wxWidgets
  • BartercastDBHandler is not implemented. getInstance() returns None


For press exposure we can only have 1 simple messagge for whats new? The spin for this release is: P2P goes 2.0 with wiki-style edits of tags and subtitles. A simple moderation algorithm using ModerationCast will be used to distribute this rich metadata. Subscriptions and blocking will be used to control spam.

Arno: Do you really see a market for subtitle adding?

An crucial shift for Tribler is that we address the swarm duplication problem. Over 100+ swarms exist with the same video content for popular items. To deliver true Video on Demand we need to solve that problem. Ideally all Tribler peers always join the same & fastest swarm for an item. Tribler peers now only meet very infrequently in swarms ensuring that both give-to-get and BarterCast work inefficiently.

With ModerationCast we can begin by making 1 swarm more equal then others with the same content.

Improving Social Networks

  • Always keep TCP connection with friends
  • Friend invitation
    • Remote person search to find your friends. Search on more profile details (city, email, country, phone)
    • Send friends-invitation with invitation-text (like linked-in).
    • Design and think about: showing of friendships of persons/friends.
    • Display incoming requests for friendship (when both online)
    • Track the status of a friendship request (pending/waiting delivery, delivered, accepted)
  • Simple instance message (max. 250 chars)
  • Knowing friend's status: online/ready for boosting/currently helping etc.
  • Friend's recommendation on items
    • Unlimited searches in your megacache
    • Unlimited download of .torrent files from search results
    • Auto-booster: Use all idle online friends when downloading (automatically enabled)

Keeping Communication Status for BuddyCast

Each peer keeps the history of communication with other peers. When connected with a contacted peer again, avoid including redundant information in the message.

  • Data structure and database support
  • Record communication history
  • Check history and decide the content in message

Arno: I think this is a wrong optimization that is not worth the effort as the majority of bandwidth consumed by the overlay swarm is not by buddycast messages, but by torrents, i.e. METADATA messages.

Other Tasks

Arno: Which is?

  • Easy User Feedback
    • Easy submission of bugs on from pull-down menu in Tribler
    • Direct access to from pull-down menu in Tribler
  • Megacache is easy to find, but protected against deletion
    • Split between MegaCache? and bulky torrent2 directory
    • Discovered_torrents are a read-only directory within tribler_downloads dir
    • The uninstaller deletes all discovered torrents and Berkeley DB files, except PermID and mypreferences.db

  • Arno: Integrated video player?