trans-autoclean – Auto Remove Completed Torrents from Transmission

Filed in Software Developement Leave a comment

Do you have an awesome set & forget server setup that automatically grabs torrents for you in the background? Do you use transmission-daemon to accomplish this? Have you ever wondered why there’s no way to automatically remove completed torrents? I sure have.

I started using FlexGet about a year ago, I even wrote my own plugin to handle magnet links back when I was still using rtorrent. I left rtorrent because transmission has really matured and is much easier to work with (RPC-wise). The problem I kept facing is that every now and then I would check on the web interface and found a large number of completed torrents just sitting there. This became a semi-regular task, log into the web interface, clear the completed torrents. Today I decided that this is a very simple problem to solve so I’ll just kill an hour and make this work. Turns out it only took about 15 minutes, but I spent the other 45 creating a github account, project, and writing this entry.

Anyways, here is the project:

This script is perfect for those who have a couch potato like setup. Hopefully some of you find it useful.


LINQ, GroupJoin, and Left Outer Joins

Filed in Software Developement Leave a comment

This is a topic which involves me scouring the internet every time I need to do this task. outer joins in LINQ are one of the few LINQ concepts that is not very simple to execute.

Essentially, an Outer Join maps to GroupJoin. GroupJoin is almost identical to Join, except that your right side lambda parameter is a collection (of potentially zero items) instead of an object reference. Because it is a collection it doesn’t really help you out if you need to do a real left outer join. To solve this we make use of SelectMany and DefaultIfEmpty LINQ methods.

SelectMany will allow us to expand the collection, and DefaultIfEmpty will retain the empty collections, together we can supply a value of null (or whatever you want) to a column that is not joined. Below is an example to illustrate.

    .GroupJoin(Orders, x => x.CustomerID, x => x.CustomerID, (a, b) => new { a.Name, b })
    .SelectMany(x => x.b.DefaultIfEmpty(), (a, b) => a.Name, OrderID = (b == null ? (int?)null : b.OrderID)

, , , ,

Refusal of Legal Tender

Filed in Misc Leave a comment

The other day I tried to pay for a meal with a $100 bill, the older bill, before the polymer bills. The result was that my payment was refused, on grounds that the bill could likely be counterfeit lacking the new counterfeit protections of the polymer bills. Now in this instance I was having lunch with a friend who was able to exchange my older $100 bill for a newer polymer bill, which the merchant subsequently accepted. However I started to think after departing, can the merchant really do this? The answer is yes, unfortunately. Legally, a merchant is not required to accept your form of payment. In order to settle the debt, both parties must agree upon the method of payment. So if the merchant decides they don’t accept bills of certain denominations then you’re pretty much out of luck, well, most of the time.

There is one loophole in this rule, if your legal tender is for repayment of an existing debt. So if I had eaten my meal under terms of credit with the merchant then they would have no ability to refuse my older $100 bill because they would be obligated to accept it. This is not really relevant anyways, because who orders a meal under terms of credit. But I started to wonder, had I been alone and had no other form of payment (which I didn’t) what would have occurred. Realistically, the merchant probably would have accepted the older $100 bill, because really, it was either take a (very small) gamble on a counterfeit $100 bill or receive nothing at all. However, had they gone some other direction, perhaps with a promissory note (considering I do eat there somewhat regularly) they would have legally been obligated to immediately accept the $100 bill because the debt transitioned into a repayment from a payment.

Another fact that bothered me about this whole situation is that normally the merchant displays a sign before the customer enters the establishment to inform of the legal tender acceptance rules that they employ. This serves to inform the customer what would be considered acceptable payment before any services are performed (or products exchanging ownership). This particular merchant did not have such a notice available (anywhere), I was only informed of this rule by the merchant as I handed the $100 bill. Legally, I don’t know where this lies, but I would assume that the lack of notification changes nothing, still it is worth noting.

Finally, I did some research on the statistics of counterfeit bills. From an article back in 2008 (before polymer bills), I am informed that of all the Canadian counterfeit transactions the overwhelming majority are with $20 notes, 66% to be precise. Compared with 5% for $100 notes, it’s clear that $20 notes are significantly more commonly counterfeited on average. If we look at this on the average case, we can suggest that on average a merchant will accept roughly 13 times more counterfeit $20 notes than counterfeit $100 notes. So if we expand that out dollar for dollar, a merchant should accept an extra $160 in counterfeit $20 notes on average ($20 x 13 – $100). So mathematically, a merchant would stand to lose less money to counterfeit transactions by refusing to accept older $20 notes (which are still widely accepted today) than by refusing to accept $100 notes. The practice by merchants to refuse older $100 notes (and $50 notes, as is often seen), has only compounded their problem by increasing the likelihood of a $20 note (and $10 notes) of being counterfeit. Why would a counterfeiter produce notes that he or she has difficulty exchanging?