11月 292015
 

为了防止自己在周末就这么荒废过去,特列此TODO List,争取每周总结一下进度。

1)硬盘裁员计划

计划将硬盘中的文件都传到百度网盘中。目前(2015.12.06)进度:

申请网盘:7个14个

申请邮箱:13个18个

已完成:TV大陆

进行中:TV日本、Movie欧美

2)光盘销毁计划已完成(2016.01.23)

计划将996张光盘里面的文件都拷贝到硬盘,并视内容上传至网盘或者放到备份的硬盘中。

尚未开始。

3)下载机更换计划

计划将下载机从Y460更换为树莓派2。降低功耗。

尚未开始。已完成(2015.12.05)

 Posted by on 2015/11/29 at 14:18
11月 182015
 

随着经济增长日趋缓慢,各行各业纷纷进入寒冬,并开启了一轮又一轮的裁员计划。

对于火星猫我而言,最多的“雇员”非硬盘莫属了~想当年毕业回家的时候,让老爸老妈每人带了3个硬盘,结果还被安检一个一个拿出来检查23333,好不容易才运到家里。然而工作后死性不改,依旧维持3个月1块2T/3T硬盘的速度购买新硬盘,结果就是一共买了30TB+的硬盘。。

然而,随着下载数据的愈发增加(TTG大法好~),一直新增硬盘总不是一个办法:一方面要持续的经济投入,另一方面还要维护数据的存放分类。于是乎,是时候给硬盘来一次裁员了~

有那么几个问题需要解决:

1)存哪?

这个问题并不大,现在免费的网盘多如牛毛,百度云、微云,一抓一大把,且动辄2T、10T~虽然要手机验证,但是并不限制一个手机验证多个网盘~

2)数据可恢复性

由于存网盘的数据本身来源于互联网,如果有不和谐的内容被用户举报,那么我这一份数据也没法访问。所以解决方法是:重新生成文件。具体做法是:对于电视剧这些,用MediaCoder进行重编码,降低码率;对于电影,用ffmpeg重新封装(非重编码),使得文件的hash值产生变化,以避免举报。

3)上传速度

感谢公司的百兆无限时宽带网络~短短5天,就上传了1.5TB的数据~秒杀99.9%的用户哦~~

bdy

 

最后~我们的目标是:上传30TB!彻底解放硬盘~~

 Posted by on 2015/11/18 at 22:44
8月 232015
 

uTorrent是一个很小巧的BT/PT下载软件。然而,由于实现的原因,在长时间挂PT站点的情况下,uTorrent会占据大量的内存,严重影响系统性能,同时也降低了上传下载速度。

原因分析:

由于uTorrent需要经常读取多个文件(特别是挂PT站点),所以会产生大量的文件缓存。windows系统对于缓存的管理能力有缺陷,导致内存无休止增长。

解决方法:

1)uTorrent3.2版本及之前:关闭系统缓存

在uTorrent选项-设置-高级-缓存中,勾选 禁用系统读取缓存 和 禁用系统写入缓存

2)uTorrent3.3版本及之后:使用setsystemfilecachesize控制系统缓存

由于uTorrent设置中取消了禁用系统缓存,所以只能手动控制系统的缓存了。

下载setSystemFileCacheSize,解压后双击打开,可以看到系统的文件缓存并没有限制。

打开命令提示符(运行-cmd),通过cd命令指定到文件夹之后,执行:SetSystemFileCacheSize.exe 512 1024

然后再去双击打开SetSystemFileCacheSize.exe,可以看到已经设置过系统文件缓存了~

注意:这里的512 1024代表最小缓存、最大缓存量,单位是MB。

systemCache

下载链接:setsystemfilecachesize

 

需要注意的一点是:如果采用SetSystemFileCacheSize的方法,那么每次重新启动计算机后都会失效,需要重新设置,可以放到启动任务里~

1月 082015
 

周一早上发现剃须刀无法使用了,以为没电了,就没管它。晚上换上新电池还是不能用,觉得时间久了大概寿命也到了,遂在淘宝上买了个新的。无奈新剃须刀迟迟没有送到,于是晚上心血来潮想修修看。

既然很大可能是电池的原因,那么就先检查电池盒吧~不看不要紧,一看吓一跳,电池盒的一个垫片已经完全腐蚀了,用万用表测量发现电阻无穷大。好吧,这么快就找到原因了~那么就修修看吧~

IMG_20150108_232902

 

上图是腐蚀了的电极

方法当然很简单啦,自己找一根导线连接被腐蚀垫片的两端即可。可哪来电线呢?嘻嘻,幸好之前各种坏掉电器的充电线都没扔,随手找了一根,剪开,利用以前学的剥电线的技术,分分钟搞定~ IMG_20150108_234130上图是剪开的电线(一红一绿,绿的抽出来用了,红的还留在里面)。绿的是剥线示意(两端剥开)

第二步,就要将电线连接金属片了~如下图所示:一端连电池,一端连电路接触点IMG_20150108_232832

然后就能用啦~不过也有缺点,换电池要重新连接电极。不过念在一年也换不了几次电池,应该问题不大~

 

剩下的问题是:还在快递中的新剃须刀,是不是该7天无条件退货呢~~

 

 Posted by on 2015/01/08 at 23:48
6月 092014
 

毕业旅行安排如下(所以如果某个飞机失联了,好歹知道我在不在上面~)

2014年6月11日 HU7147 北京–成都

2014年6月12日 3U8607 成都–九寨沟

2014年6月14日 CA4398 九寨沟–重庆

2014年6月16日 SC4759 重庆–西安

2014年6月17日 T42 西安–北京

 Posted by on 2014/06/09 at 22:27
6月 042014
 

1)拔智齿前:(拍X光片后)

医生:你确定要今天拔掉这颗智齿么?

我:诶?可以不拔掉的么?

医生:不行,现在不拔,以后更麻烦。

我:……(尼玛,我来校医院就是拔智齿的,又不是来拍片的!)那就拔吧~

医生:首先,签一下知情同意书。

我:诶?还会拔出什么问题么?

医生:嘿嘿~

………………

2)拔智齿中:

医生:你的智齿是阻生智齿,得切掉一半然后把另一半揪出来。

我:哦~

医生:(我切我切我切切切~)后面会敲几下锤子,可能有些疼啊~忍耐一下~

我:呜—(手术中无法说话)

医生:(敲了10下,好像没什么动静,然后有开始磨啊磨)

医生:(又敲了13下,还是没什么动静,继续磨)

医生:(又敲了12下,还是没有动静!)这智齿还挺硬的啊~还得敲几下,忍一下啊~

我:………………

医生:(让护士来敲,敲了9下还是没有动静,然后医生再敲了6下,终于下来了!)呼~下面缝针啊~

我:呜—

医生:(缝完了一针)洞有点大啊~再缝一针~

我:………………

3)拔牙后:

医生:牙肿了牙疼是正常反应啊~肿了吃止肿药,疼了吃止疼药~一周后过来插线~回去吧~

4)回到宿舍,当天晚上:

我:要不要吃止疼药呢~

室友:疼了就吃,不疼就不吃~

我:介于两者之间呢?有一点点疼,但不太疼

室友:……那就别吃了~

5)第二天晚上,可以漱口了:

我:(看了漱口水的说明书)难怪上两次拔智齿漱口的时候觉得漱口水味道奇怪,原来是要在50ml温水中掺入2ml的漱口水的啊!我之前直接就用纯漱口水漱口了!

室友:= =|||

6)第二周,拆线:

医生:拔完之后感觉怎么样?有严重反应么?

我:(第二天就吃肉肉了的说,反应是啥?)没啥反应,不疼不肿,还以为出了什么问题呢!

医生:不疼还出问题啊!要不,下次再拔智齿的时候给你弄肿了让你体验一下?

我:我已经没有智齿了,都拔完了~

医生:那太可惜了!

 Posted by on 2014/06/04 at 11:29
4月 182014
 

实验室标配的电脑性能较弱,仅能提供基本的办公环境。于是,就进行了一些改造~因为改造已经很久远了,所以就贴出完工后的电脑“内饰”

猫の电脑

 

具体包括:

1)2条4G的内存(原配2*2G,加上之后一共12G)

2)GTX 650 Ti 独立显卡

3)1TB 额外的机械硬盘(原配500GB硬盘)

4)128GB固态硬盘

于是,Win7评分就华丽丽的上了7~并且,CPU(i3-2120)成为了最低得分项……想想就有点小激动呢~

win7_mark

 

总结:

少壮不努力,老大修电脑……

 Posted by on 2014/04/18 at 21:00
1月 142014
 

最近写一个代码的时候,发现cvDFT在32位下比64位下速度还快,觉得很不可思议。于是查看了OpenCV的源代码,发现了如下的说明:

//On Win64 optimized versions of DFT and DCT fail the tests (fixed in VS2010)

看来是VS2008在优化的时候会让OpenCV的DFT和DCT出错,不得已禁用了编译器代码优化,从而速度较慢。

唉~看来毕业的时候得用VS2010了~

 Posted by on 2014/01/14 at 15:26
11月 092013
 

OpenCV是很好用的开源库,不过,还是有一些BUG的~

比如,今天遇到的问题是,imdecode的执行速度很慢。

照理来说,imdecode是从内存解析一幅图像,应该比cvLoadImage还快(或者至少不慢)。

但实际上,执行的时候却是imdecode慢很多(一张图片要1秒以上)。而且很奇怪的是,在某些机器很快,某些机器就很慢。而且调用了不同版本的OpenCV速度也不同。

为什么呢?本着质疑的原则,开始查看OpenCV的源代码。

imdecode的实现在modules\highgui\src\loadsave.cpp中。结果,发现opencv也是先将内存数据写到文件然后再读取的……这不是偷懒么orz

不过,逻辑上没有问题,算法上却犯二了……OpenCV2.4.2及之前版本在实现这个函数的时候,申请了一个临时文件(C:\user\用户名\AppData\Local\Temp\下的ocvXXXX.tmp文件,其中XXXX是0~F的16进制数)。然后写这个文件,然后读。关键是,没有删除!原因是因为临时文件可能不存在(本意是如果形如ocvXXXX.tmp的文件都存在了,那么就不能再新建了,所以返回空不作操作,实际上不会走到这一步),所以最后不一定需要删除文件。于是写OpenCV的小朋友这里为了程序稳定就没有删除临时文件。如图所示:

temp2

结果就是:如果调用imdecode次数越多,速度越慢。超过65535次则每次需要枚举65535个临时文件是否存在。。这个时间对系统而言大致是1秒吧~

当然,写OpenCV的小朋友还是意识到了这个问题,至少2.4.5开始这部分代码就改成判断临时文件名是否为空,不为空则删除了。这样就不会产生临时文件堆积的问题了~

 

anyway,结论就是:

如果想从内存里面直接解析一幅图像,还是乖乖自己写到文件再读取吧~可以模仿opencv去向系统申请临时文件的说~(GetTempPathA和GetTempFileNameA函数)

 Posted by on 2013/11/09 at 13:40