Sylvain Zimmer

We’re now more than 400 torrents to seed on jamendo. That’s about 100Go. We currently use btlaunchmany.py but I don’t think that’s sustainable. So before it’s too late, I think I have to reconsider a new solution to this problem.

As we also operate the tracker, I think there’s really some cooperation needed between both sides, the tracker and our permaseeds. Here are a few of my ideas :

• We don’t need to seed files that are already seeded by many users. Let’s find a lower limit, like 5 seeds.
• But we have to make sure they really seed ! So we need to make some control on the uploaded/downloaded statistics of the client. Are they reliable ?
• Maybe some clients will send the IPs of our servers to the other bittorrent clients, or even use Azureus’ DHT. So we have to really stop seeding these files.
• As the seeds are permanent, it should be easy to store their IPs in the tracker, and turn off announce on the seeds.
• Use that ultraseeding feature ?
• Would it help to turn off the seeds when there’s no client downloading ?

Just some thoughts… TBC

YouTube just launched, it’s the flickr of video. All this “web 2.0″ stuff really got my attention last week, and we’re clearly heading to that now with jamendo. Maybe we’ll become the flickr of audio. Or something like that. Here is our todo-list to add web 2.0 “compliance” to jamendo :

• more Javascript/podcast/RSS syndication tools
• rework URLs. they are way too obscure right now
• folksonomies
• more CC integration
• test the XSPF flash player in order to be really “web only”. for P2P we’ll have to wait I guess.
• we already have a public XMLRPC API, but try to extend it a bit more.
• more social features in the website

If you think of more web 2.0 features just tell me ! We’ll see in a month what I’ll have implemented :)

We need to upgrade our dying MySQL server. It serves more than 30 databases, some of them having multi-million-row tables, for more than 10 different projects, one of them being jamendo.

With the cool book, I just began configuring from scratch our new MySQL server, with replication and all the good stuff.

So here we go. A little emerge-webrsync to sync both servers (master is” vador”, slave is “yoda” : not logical but well…)…. This is sooo long, I remember early gentoo days, it only took like 2 minutes back then :/ mysql-4.0.24 is the gentoo HEAD, we’ll stick to that. USE flags for mysql : “readline innodb tcpd ssl perl”.

Next step is creating the replication user on both master and slave :

mysql> FLUSH PRIVILEGES;
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@”192.168.0.0/255.255.255.0″ IDENTIFIED BY “xxxxxxx”;
mysql> FLUSH PRIVILEGES;

Here are my edits of the configuration for the master :

log-bin
server-id = 193 #use IP
log-bin = /home/mysql/repl/log-bin

For the slave :

server-id = 196
read-only #only accept queries from replication
master-host = 192.168.0.193
master-user = repl
master-password = xxxxxxxxxxx
master-port=3306

A few restarts later replication is working.

Oops, while reading the book I just stumbled upon the sentence “There
is currently no workaround to this problem. Make sure the power cables
are plugged in tightly !”… Quite frightening, uh ?