George wrote:GUI wise it would make a lot of sense to put the actual GUI stuff in the mediaplayer plugin. You see ideally you want to be able to play a video while you are downloading with the mediaplayer plugin, and you want to be able to pause the video if the next chunk which needs to be played is not there yet.

So if you start playing an incomplete file you could then add your custom chunk selector, and then feed phonon the video data as it comes in. If the next part of the video isn't available, you could then do like youtube and stop playing until the data is there.

This doesn't sound easy. Does Phonon have any "streaming mode" or such to automatically pause when there is no more data in the buffer? Otherwise one would have to parse the video frames and keep track of timestamps to detect when it is time to send a pause event to the player. Or is there some magic feature for this problem already implemented in Phonon?

It supports streams fairly well. You can just pass a QIODevice to it, so it should support situations when there is no data available. I already added a TorrentFileStream class, which can be used by phonon, and uses KT's internal methods to access the data of files.

It's been a while since I wrote last and although I'm rather busy these days, there has been some development.

Unfortunately I haven't been able to test if the new code works, because the method I've been using to activate my custom chunk selection class is broken yet again. Even though I didn't make any changes to that part of the code, as soon as I load my plugin, I can no longer access the context menu (right clicking on a torrent). After unloading the plugin it works again. I originally copied most of the context menu related code from the downloadorder plugin, and even though I could not find any significant differences, the downloadorder plugin works but my plugin doesn't.

I added code to keep track of the download speed of peers (averaged with an exponential weight function) by linking the calculations to the guiUpdate. So theoretically it should now assign slow peers to later chunks and fast peers to earlier chunks.

I hope to find time for bug hunting some time soon, but I can't make any promises.

There were some changes in the GUI code, you need to add this function in your Plugin class:

virtual QString parentPart() const {return "torrentactivity";}

This tells KT that the Plugin's GUI should be created in the torrentactivity instead of the main ktorrent gui

Regarding the streaming plugin, I have been a bit busy with annoying and hard to reproduce bugs, once they are fixed, the next bugfix release will be made, and I can focus once more on the streaming plugin.

If your downloading code works OK, I will use that as a basis for the chunk selection, then I can start putting things together with the media player plugin.

Ah yes, that was the issue. Thanks.

So it's definitely doing something. I don't think it's doing what it's supposed to do yet. I only watched the download of one testfile yet, and it seemed like there were almost no chunks at all downloaded outside of the high priority window. So I'll probably have to do some fine tuning with the various parameters.

Also I'm looking for a way to move slow peers to less important chunks (fast peers probably don't need moving, they simply get a high priority chunk assigned after they finished their current one). I think I might be able to tell the ChunkDownloader that the Peer has been killed, or just to releaseAllPDs altogether, or is there a better way?

seth wrote:Ah yes, that was the issue. Thanks.

So it's definitely doing something. I don't think it's doing what it's supposed to do yet. I only watched the download of one testfile yet, and it seemed like there were almost no chunks at all downloaded outside of the high priority window. So I'll probably have to do some fine tuning with the various parameters.

Also I'm looking for a way to move slow peers to less important chunks (fast peers probably don't need moving, they simply get a high priority chunk assigned after they finished their current one). I think I might be able to tell the ChunkDownloader that the Peer has been killed, or just to releaseAllPDs altogether, or is there a better way?

I have added a release function to ChunkDownload, which you can call.

How do you intend to determine which is a fast peer and which is a slow peer ?

Ah nice.

I plan to use an exponential moving average of the download speed of each peer while being unchoked. This value is easier to calculate and to keep track of than the usual average. Moreover due to the exponential decay in its weights, it represents an average of the recent download speed of that peer.

I'm not sure yet how to sort the peers into "fast" and "slow" peers exactly. The current code sorts the upper 60% of the total download speed (sum of averages) into "fast" and the lower 15% into "slow" while some in between are "normal". I'll have to do some tests to see if this behaves nicely.

I'll probably add some code to generate some kind of trace of the download so that I can run it through some statistics software for analysing.