I'm creating my own MP3s with an online service, and I'm setting the "Year" attribute in the ID3v tag, but I'm having trouble getting it to work with both Nautilis and Rhythmbox. In Nautilis, when I click on "Properties" and select the "Audio" tab, it shows "Year: Unknown". In Rhythmbox, it does the same when selecting the file "Properties" and says it's "Unknown". When I use EasyTag though, it works fine and shows the Year field set properly. I've also tried using eyeD3 to try both ID3 v1.x, v2.3 and v2.4, but they all show "Unknown".

One other observation was when I changed the year from "Unknown" to "2013" in Rhythmbox, and then closed Rhythmbox, Nautilis still showed "Unknown" for the year.

Is there something more to setting the Year field on ID3 tags that I'm missing, or is this just some subtlety between how different programs interpret the tags?


Question: Networking Questions: Serialization and Frequent Small Packets or Fewer Large Packets
Answer: When you send small messages, you have to be aware of the protocol overhead:



Imagine you are sending a 10 byte message.

A TCP header is 24 bytes, an UDP header is 8 bytes. Assuming you use UDP, you have 18 bytes in total.

But you also have the IP header, which is at least an additional 20 bytes in IPv4 or 40 bytes in IPv6. That's 38 bytes in total when you use IPv4.

And then you also have the ethernet frame around all that, which is (usually) another 42 bytes. So you are at 80 bytes. That's 7 times as much protocol overhead as the data you were sending.

As you see, sending small data messages is not very bandwidth-efficient because there is a fix-cost of 70 bytes of protocol overhead for each message. 

to visualize this better, seventy bytes is as much data as this string

But delaying small messages just so you can send more at the same time is often not a good idea either, because this will make the game feel more laggy.

There is no golden hammer solution to finding the ideal compromise for this. But all data which is available at the same time should be sent in one message instead of separating it into multiple. There is nothing to gain and a lot to lose by adding  unnecessary fragmentation on the application level.

(Image source: http://en.wikipedia.org/wiki/File:UDP_encapsulation.svg)