カテゴリー
PC

Surface Go 2の充電

Surface Go 2 (Pentium 4425Y / 8GB/ 128GB)を買ったので、手持ちのUSB PD対応の充電器やモバイルバッテリーで充電してみました。

USB Type-C端子で充電しながら、USBテスタを中間に入れて充電時の電圧を測りました。電流についてはSurface側のバッテリーの減り具合にも依存することなので、充電器ごとに最大電圧とその電圧における最大電流値を示すにとどめておきます。

充電器結果電圧対応最大電圧/電流
Anker PowerPort Atom PD 2OK20V20V=3A
Anker PowerCore 10000 PD ReduxOK15V15V=1.2A
ミヨシ IPA-C01OK14.5V14.5V=2A
Anker PowerCore III Fusion 5000NG9V=2A

この調査から以下の事が分かりました。

  • USB PDでも、15Vや14.5V(Optional)以上が出力できるものでないと充電できない。12V(現在ではOptional)で充電できるかは不明。
  • 電圧は20V・15V・14.5Vの中から充電器が対応する最大のものが選ばれる。Surface Go 2に付属しているACアダプタ(Surface Connect端子用)は15Vであるが、USB Type-C端子を使えば20Vで充電できる。
  • 充電の経過に応じて電圧が切り替わったりはしない。
  • 充電器側で、電圧における電流値が少なくとも1.2Aあれば充電できる。USB PDにネゴシエーションがあることを考えると、ちゃんとSurface側で受け入れていると思われる。受け入れる最低電流値があるかどうかは不明。

余談ですが、発売日に予約したAnker PowerCore III Fusion 5000、Surface Go 2に充電できなかったので、この調査が終わった後に友達に売ってしまいました。15Vが出れば良かったのに。

参考文献:

カテゴリー
PC

iTunesで購入した曲の題名などがローマ字になった場合の対処方法

音楽の購入も管理もiTunesを使っているのですが、購入した曲の曲名や歌手名などが、稀にローマ字表記になっている事に気づきました。対処法を記します。

(2020/4/10現在の対処方法です。ググると昔の情報とかがヒットして、操作方法が違って戸惑ったので、自分で書くことにしました)

手順は3ステップです。

  1. 問題が発生した曲をiCloudライブラリから削除する。
  2. 削除した曲を購入済み項目に再び表示させる
  3. 購入済み項目から削除した曲を再ダウンロードする。

まず、問題が発生した曲をiCloudライブラリから削除します。

次に、削除した曲を再びダウンロードできるように、「購入済み」に表示させる操作を行います。

「アカウント」→「マイアカウントを表示」から、「iTunes in the Cloud」内の「非表示の購入済みアイテム」で「管理」をクリックします。

先ほど削除した曲(アルバム)が表示されていると思うので、「表示する」をクリックします。

これで曲が再びダウンロードできるようになりました。

ダウンロードします。まず「ストア」の「購入済み」を選択します。

先ほど削除した曲(アルバム)があるので、雲マークをクリックしてダウンロードします。

確認します。曲名が日本語表記に戻りました。

カテゴリー
PC

Pythonで標準エラー出力を潰した後は、例外のログを取りましょう

Pythonを使っているときに、ログを取るのを怠ってエラーが見つからずに苦労したので、ちゃんとログを取りましょう、という話です。(Pythonに慣れている方には、おそらく常識レベルの話だと思います)

普通に処理をしている場合は、予期しない例外が発生すると標準エラー出力に例外のスタックトレースが出力されます。しかし、標準エラー出力を潰した後はスタックトレースが出力されません。

以下のような場合に問題になります。

  • daemon化する場合
  • スレッドを実行する場合

順に説明します。

daemon化する場合

double forkによるdaemon化については、Pythonでは以下のページの例のように行います。

Double forkによるプロセスのデーモン化と、ファイル変更時の自動サーバーリロードの実装 (Python)

この場合、標準エラー出力が潰されているので、 daemon化した後に例外が発生しても、 例外のスタックトレースはどこにも出力されません。

以下のようにすると、例外のログがloggerで出力できます。

def main():
    logger = getLogger()
    handler = FileHandler("./test.log")
    logger.addHandler(handler)

    daemonize() # double forkした後に標準エラー出力を潰す

    try:
        do_process() #ここで例外が発生したら、下のexceptでキャッチする
    except Exception as e:
        logger.exception("Exception {0} occured".format(e))

    

スレッドを実行する場合

さらに、daemon化してからスレッドを実行する場合、親スレッドのtry-exceptではスレッド内での例外は捕捉されず、例外のスタックトレースはどこにも出力されません。 スレッドのrun()で、例外を捕捉してログを出力する必要があります。

class TestThread(threading.Thread):
    _logger = getLogger(__name__)

    def run(self):
        try:
            self._do_process() #ここで例外が発生したら、下のexceptでキャッチする
        except Exception as e:
            self._logger.exception("Exception {0} occured".format(e))

def main():
    logger = getLogger()
    handler = FileHandler("./test.log")
    logger.addHandler(handler)

    daemonize() # double forkした後に標準エラー出力を潰す

    try:
        thread = TestThread()
        thread.start() # thread.run()で例外が発生しても、このtry-exceptでは捕捉できない
    except Exception as e:
        logger.exception("Exception {0} occured".format(e))

そんなこんなでうじゃうじゃ。

カテゴリー
PC

昨晩のmirakurunのエラーログ

4/1の3:08にmirakurunがエラーで再起動していたのでその時のログをメモ。

まず、mirakurun.stdout.log

<--- Last few GCs --->

[22698:0x27abf40] 120047592 ms: Scavenge 57.6 (269.9) -> 53.7 (269.9) MB, 2.7 / 0.0 ms allocation failure
[22698:0x27abf40] 120048005 ms: Scavenge 57.6 (269.9) -> 53.7 (269.9) MB, 2.1 / 0.0 ms allocation failure
[22698:0x27abf40] 120048221 ms: Scavenge 57.6 (269.9) -> 55.6 (269.9) MB, 3.2 / 0.0 ms allocation failure
[22698:0x27abf40] 120048241 ms: Scavenge 57.6 (269.9) -> 57.6 (277.9) MB, 5.1 / 0.0 ms allocation failure

<--- JS stacktrace --->
Cannot get stack trace in GC

次に、mirakurun.stderr.log

FATAL ERROR: Scavenger: semi-space copy
Allocation failed - process out of memory
1: node::Abort() [Mirakurun: Server]
2: 0x11e73ec [Mirakurun: Server]
3: v8::Utils::ReportOOMFailure(char const*, bool) [Mirakurun: Server]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [Mirakurun: Server]
5: 0xad230b [Mirakurun: Server]
6: v8::internal::Scavenger::ScavengeObject(v8::internal::HeapObject**, v8::internal::HeapObject*) [Mirakurun: Server]
7: v8::internal::Scavenger::Process(v8::internal::Scavenger::Barrier*) [Mirakurun: Server]
8: v8::internal::ScavengingTask::RunInParallel() [Mirakurun: Server]
9: v8::internal::ItemParallelJob::Task::RunInternal() [Mirakurun: Server]
10: v8::internal::ItemParallelJob::Run() [Mirakurun: Server]
11: v8::internal::Heap::Scavenge() [Mirakurun: Server]
12: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [Mirakurun: Server]
13: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [Mirakurun: Server]
14: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [Mirakurun: Server]
15: v8::internal::IncrementalStringBuilder::Extend() [Mirakurun: Server]
16: v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handle, bool, v8::internal::Handle) [Mirakurun: Server]
17: v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handle, bool, v8::internal::Handle) [Mirakurun: Server]
18: v8::internal::JsonStringifier::SerializeArrayLikeSlow(v8::internal::Handle, unsigned int, unsigned int) [Mirakurun: Server]
19: v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handle, bool, v8::internal::Handle) [Mirakurun: Server]
20: v8::internal::JsonStringifier::Stringify(v8::internal::Handle, v8::internal::Handle, v8::internal::Handle) [Mirakurun: Server]
21: v8::internal::Builtin_JsonStringify(int, v8::internal::Object**, v8::internal::Isolate*) [Mirakurun: Server]
22: 0x2c33ba40697d

その時のメモリ使用量グラフ

カテゴリー
PC

4Kモニタ導入

iiyamaのProLite B2875UHSUという28インチ4Kモニタを導入しました。

以下とりあえず箇条書き。後で清書するかも。

  • 重量は7.5kg。最近の液晶モニターとしては重いと思いますが、リプレース元のHD2441W(2007年に買ったFull HD)が10.3kgだったので、個人的にはむしろ軽量化。
  • コントラスト拡張をOnにすると、輝度の設定ができなくなるので、とても明るくなって使いづらいです。常用するかどうかは検討中。
  • 「ディスプレイ設定」で「テキスト、アプリ、その他の項目のサイズを変更する」を「150%(推奨)」にして使っています。これより小さいと確かに辛い。
  • ドットピッチが細かくなってフォントレンダリングが綺麗になるので、今まで使っていたMacTrayは無効化しました。
  • 上の状態でExcelの新規ワークシートを開くと、AM(39)列67行まで1画面で表示されます。これは広い! (Full HDのスケーリング100%だとAC(29)列49行まで)
  • Firefoxの表示がすごく小さくなるので、about:configからlayout.css.devPixelsPerPxを1.5に
  • Janetterの表示もすごく小さくなるので、フォントサイズを「大きめ」などにして対処しました。ただこれだと文字がボケます。Creators Update 2で追加された高DPI設定も指定でき、それだと文字はボケないのですが、今度はアイコン等が小さすぎるという問題が発生。高DPI用のテーマを作るか、カスタムCSSで対処するか。