Gain­ing space on An­droid after ART->Dalvik switch (root ac­cess re­quired)

I (still) use a Nexus S phone. I am us­ing Cy­ano­gen­mod on it. After an art­icle in a com­puter magazine I de­cided to give the ART-​runtime a try in­stead of the de­fault Dalvic-​runtime. Un­for­tu­nately I do not have enough free space free (and all what I can is moved to the USB stor­age already) to really use the ART-​runtime.

After switch­ing back to the Dalvic-​runtime, I had only 23 of the pre­vi­ously avail­able space free. After a little bit of look­ing around I found /​data/​dalvik-​cache. I de­leted with a file man­ager the con­tent of the dir­ect­ory (you will get some “app crashed/​died” mes­sages) and re­booted the phone (this is not the same as format­ting the cache par­ti­tion in the re­cov­ery sys­tem).

Dur­ing boot it pop­u­lated the dir­ect­ory again and now I have more than 43 of free space on the in­ternal stor­age.

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

Up­dat­ing FreeBSD 8.2 (or 9.x) to 10 (beta4)

This is a little de­scrip­tion how I re­motely (no con­sole, booted into multi-​user dur­ing up­date, no ex­ternal ser­vices like jails/​httpd/​… run­ning) up­dated a FreeBSD 8.2 to 10 (beta4) from source. This should also work when up­dat­ing from FreeBSD 9.x. Note, I had already switched to ATA_​CAM on 8.2, so not in­struc­tions for the name change of the ata devices. No IPv6, WLAN or CARP is in use here, so changes which are needed in this area are not covered. Read UPDATING care­fully, there are a lot of changes between ma­jor re­leases.

What I did:

  • up­date /​usr/​src
  • make build­world
  • re­place “make ” in /usr/src/Makefile.inc1 with ${MAKE} (two times, one for “VERSION”, one for “BRANCH”)
  • verify ker­nel con­fig for changes needed (run­ning “con­fig MyKer­nel” in /​usr/​src/​sys/​YourArch/​conf/​ helps to identify syn­tax prob­lems), sorry I didn’t take notes, but I diffed the old and the new GENERIC con­fig and added/​removed ac­cord­ing to my in­terests
  • /usr/obj/…/src/usr.bin/bmake/make buildker­nel KERNCONF=MyKernel
  • /usr/obj/…/src/usr.bin/bmake/make in­stallker­nel KERNCONF=MyKernel KODIR=/boot/kernel.10
  • merge­mas­ter –p
  • /usr/obj/…/src/usr.bin/bmake/make in­stall­world DESTDIR=/somewhere/test
  • mk­dir /​root/​net10; cp /​somewhere/​test/​rescue/​ifconfig /​somewhere/​test/​rescue/​route /​root/​net10
  • cre­ate the file /etc/rc.10update with:
    case $(un­ame –r) in
    ex­port MYIFCONFIG
    ex­port MYROUTE
  • change the files (stu­pid ap­proach: grep for “if­con­fig” and “route” in /etc/rc.d to identify files which need to change, I skipped files which I iden­ti­fied as not needed in my case, if you use pf/​IPv6/​bridge/​…, you may have to change some more files) /etc/rc.d/auto_linklocal /etc/rc.d/defaultroute /etc/rc.d/netif /etc/rc.d/netwait /etc/rc.d/routing: add “. /etc/rc.10update” at the end of the block with “. /etc/rc.subr”, change the “ifconfig”-command to ${MYIFCONFIG}, change the “route”-command to ${MYROUTE}
  • change /​etc/​net­work.subr: add “. /etc/rc.10update” be­fore the first func­tion, change the “ifconfig”-command to ${MYIFCONFIG}, change the “route”-command to ${MYROUTE}
  • make sure that the changes you made are 100% cor­rect, rather triple-​check than to not check at all (you will be locked out if they are not 100% OK)
  • stop any jails and make sure they do not re­start at boot
  • de­ac­tiv­ate the gmir­ror of the root-​fs, if there is one (it is maybe easier to ask a re­mote hand to swap the boot or­der in case of prob­lems)
  • here you could just a re­boot of the server to come back to your cur­rent OS ver­sion, so make sure that the modi­fic­a­tions in /​etc did not cause any prob­lems with the old ver­sion (in case you see prob­lems with the v10 ker­nel), but if you do not have a re­mote con­sole to single-​user mode you have no chance to dir­ectly fix the prob­lem (risk mit­ig­a­tion de­scribed above), no mat­ter which ver­sion of the ker­nel you boot
  • next­boot –k kernel.10
  • shut­down –r now
  • lo­gin
  • check dmesg
  • op­tional: mv /​boot/​kernel /boot/kernel.8
  • make in­stallker­nel KERNCONF=MyKernel
    to have a v10 /​boot/​kernel
  • make in­stall­world
  • merge­mas­ter
  • make delete-​old
  • rm –r /etc/rc.10update /​root/​net10
  • change rc.conf: add “inet” in ifconfig-​aliases
  • re­view sysctl.conf for out­dated entries
  • shut­down –r now
  • op­tional: rm –r /boot/kernel.10
  • en­able jails again (or later… up­dat­ing jails is not de­scribed here)
  • activate/​resync mirror(s)
  • re­build all ports (at­ten­tion: new pkg sys­tem)
  • make delete-​old-​libs
  • re­boot again to make sure everything is OK after the port-​rebuild and re­moval of old libs (a console.log (syslog.conf) helps here

Cal­cu­lat­ing the tar­get size of H264 videos

From time to time I con­vert videos to H264. When I do this I want to get the best qual­ity out of a give files­ize. This means I cre­ate VBR videos. The ques­tion here is, how big the tar­get video file shall be.

After search­ing around a little bit in the net I found a for­mula which is sup­posed to give a hint about the tar­get files­ize. Nat­ur­ally this de­pends on the en­coder (or even the encoder-​version), the en­coder set­tings and even the video.

The for­mula is at least a good hint for my use, so I wrote a script which cal­cu­lates sev­eral files­ize val­ues for a given video (based upon the out­put of me­di­ainfo, which the scripts ex­pects in a file with the fi­le­name as an ar­gu­ment to the script). It cal­cu­lates a CBR and a VBR value for a given video based upon the width, height and dur­a­tion. It should work on all sys­tem with a POSIX com­pat­ible shell.

Ex­ample out­put for a video from my HD-​ready cam, ori­ginal files­ize 1.8 GB:

Width: 1280, Height: 720, FPS: 50.000, Time: 1424, Mo­tion: 2
Per second: 6451200.000 bps /​ 6300 Kibps
Total CBR: 1148313600 bytes /​ 1121400 KiB /​ 1095 MiB
Total VBR: 861235200 bytes /​ 841050 KiB /​ 821 MiB
Width: 1280, Height: 720, FPS: 50.000, Time: 1424, Mo­tion: 3
Per second: 9676800.000 bps /​ 9450 Kibps
Total CBR: 1722470400 bytes /​ 1682100 KiB /​ 1642 MiB
Total VBR: 1291852800 bytes /​ 1261575 KiB /​ 1232 MiB
Width: 1280, Height: 720, FPS: 50.000, Time: 1424, Mo­tion: 4
Per second: 12902400.000 bps /​ 12600 Kibps
Total CBR: 2296627200 bytes /​ 2242800 KiB /​ 2190 MiB
Total VBR: 1722470400 bytes /​ 1682100 KiB /​ 1642 MiB

There are 3 sec­tions, the dif­fer­ence is the “mo­tion” value. It is a kind of mul­ti­plic­ator de­pend­ing on the amount of mo­tion in the video. For the videos I made my­self (fam­ily videos, and even some videos of vol­ley ball games), the first sec­tion seems to be just fine. So I re­duced the ori­ginal MP4 file to about 50% (not vis­ible here is the au­dio size, nor­mally I copy the ori­ginal au­dio un­mod­i­fied).

For the curi­ous ones, the for­mula is

width_​in_​pixels * height_​in_​pixels * fps * motion_​value * 0.07

for the bps value. The CBR value is

bps * playtime_​in_​seconds /​ 8

and the VBR value is

3 /​ 4 * CBR_​value.

Al­gorithm to de­tect repo-​copies in CVS

FreeBSD is on its way to move from CVS to SVN  for the ver­sion con­trol sys­tem for the Ports Col­lec­tion. The de­cision was made to keep the com­plete his­tory, so the com­plete CVS re­pos­it­ory has to be con­ver­ted to SVN.

As CVS has no way to re­cord a copy or move of files in­side the re­pos­it­ory, we copied the CVS files in­side the re­pos­it­ory in case we wanted to copy or move a file (the so called “re­po­copy”). While this al­lows to see the full his­tory of a file, the draw­back is that you do not really know when a file was copied/​moved if you are not strict at re­cord­ing this info after do­ing a copy. Guess what, we where not.

Now with the move to SVN which has a build-​in way for copies/​moves, it would be nice if we could re­cord this info. In an in­ternal dis­cus­sion someone told its not pos­sible to de­tect a re­po­copy re­li­ably.

Well, I thought oth­er­wise and an hour later my mail went out how to de­tect one. The longest time was needed to write how to do it, not to come up with a solu­tion. I do not know if someone picked up this al­gorithm and im­ple­men­ted some­thing for the cvs2svn con­verter, but I de­cided to pub­lish the al­gorithm here if someone needs a sim­ilar func­tion­al­ity some­where else. Note, the fol­low­ing is tailored to the struc­ture of the Ports Col­lec­tion. This al­lows to speed up some things (no need to do all steps on all files). If you want to use this in a gen­eric re­pos­it­ory where the struc­ture is not as reg­u­lar as in our Ports Col­lec­tion, you have to run this al­gorithm on all files.

It also de­tects com­mits where mul­tiple files where com­mit­ted at once in one com­mit (sweep­ing com­mits).


  • check only category/​name/​Make­file
  • gen­er­ate a hash of each commitlog+committer
  • if you are memory-​limited use ha/​sh/​ed/​dirs/​cvs-​rev and store path­name in the list cvs-​rev (path­name = “category-​name”) as stor­age
  • store the hash also in pathname/​cvs-​rev

If you have only one item in ha/​sh/​ed/​dirs/​cvs-​rev in the end, there was no re­po­copy and no sweep­ing com­mit, you can de­lete this ha/​sh/​ed/​dirs/​cvs-​rev.

If you have more than … let’s say … 10 (sub­ject to tun­ing) path­names in ha/​sh/​ed/​dirs/​cvs-​rev you found a sweep­ing com­mit and you can de­lete the ha/​sh/​ed/​dirs/​cvs-​rev.

The meat

The re­main­ing ha/​sh/​ed/​dirs/​cvs-​rev are prob­ably re­po­cop­ies. Take one ha/​sh/​ed/​dirs/​cvs-​rev and for each path­name (there may be more than 2 path­names) in there have a look at pathname/​. Take the first cvs-​rev of each and check if they have the same hash. Con­tinue with the next rev-​number for each un­til you found a cvs-​rev which does not con­tain the same hash. If the num­ber of cvs-​revs since the be­gin­ning is >= … let’s say … 3 (sub­ject to tun­ing), you have a can­did­ate for a re­po­copy. If it is >=  … 10 (sub­ject to tun­ing), you have a very good in­dic­ator for a re­po­copy. You have to pro­ceed un­til you have only one path­name left.

You may de­tect mul­tiple re­po­cop­ies like A->B->C->D or A->B + A->D + A->C here.

Write out the re­po­copy can­did­ate to a list and de­lete the ha/​sh/​ed/​dirs/​cvs-​rev for each cvs-​rev in a de­tec­ted se­quence.

This finds re­po­copy can­did­ates for category/​name/​Makefile. To de­tect the cor­rect repocopy-​date (there are maybe cases where an­other file was changed after the Make­file but be­fore the re­po­copy), you now have to look at all the files for a given repocopy-​pair and check if there is a match­ing com­mit after the Makefile-​commit-​date. If you want to be 100% sure, you com­pare the com­plete commit-​history of all files for a given repocopy-​pair.

Free DLNA server which works good with my Sony BRAVIA TV

In sev­eral pre­vi­ous posts I wrote about my quest for the right source format to stream video to my Sony BRAVIA TV (build in 2009). The last week-​end I fi­nally found some­thing which sat­is­fies me.

What I found was ser­viio, a free UPnP-​AV (DLNA) server. It is writ­ten in java and runs on Win­dows, Linux and FreeBSD (it is not lis­ted on the web­site, but we have an not-​so-​up-​to-​date ver­sion in the ports tree). If ne­ces­sary it transcodes the in­put to an ap­pro­pri­ate format for the DLNA ren­derer (in my case the TV).

I tested it with my slow Net­book, so that I was able to see with which in­put format it will just re­mux the in­put con­tainer to a MPEG trans­port stream, and which in­put format would be really re-​encoded to a format the TV un­der­stands.

The bot­tom line of the tests is, that I just need to use a sup­por­ted con­tainer (like MKV or MP4 or AVI) with H.264-encoded video (e.g. en­coded by x264) and AC3 au­dio.

The TV is able to chose between sev­eral au­dio streams, but I have not tested if ser­viio is able to serve files with mul­tiple au­dio streams (my wife has a dif­fer­ent mother lan­guage than me, so it is in­ter­est­ing for us to have mul­tiple au­dio streams for a movie), and I do not know if DLNA sup­ports some­thing like this.

Now I just have to re­place min­idlna (which only works good with my TV for MP3s and Pic­tures) with ser­viio on my FreeBSD file server and we can for­get about the disk-​juggling.