樂園日記

2021年4月14日，星期三

Youtube頻道新增八個語文翻譯，西班牙文、德文、泰文、越南文、韓文、義大利文、荷蘭文、印尼文，目前總計更支援13個語文。

下個月預備支援以下八個語文：馬來文、高棉文、阿拉伯文、瑞典文、尼泊爾文、挪威文、俄文、孟加拉文。

2021年4月8日，星期四

罕見發生磁碟機檔案錯亂的問題，把SD卡拔除來，在Windows下修復之後，即恢復正常運行。

這個問題，早在199X年，常常發生，三不五時就要修復一下，沒想到在2021這個檔案系統已經不知道發展到何種規格的年代，還是發生了這樣的問題。

本以為是樹莓派機子出了問題，因為連到HDMI的電視，沒有任何螢幕顯示！把SD卡拿下來，拿到Windows下讀，還可讀出來，只不過提示說，檔案系統可能發生問題，需要修復。

至於為什麼沒出現螢幕，這個就不再繼續往下追了，因為另一台4B的顯示是正常的，3B的這台，用在伺服器上，沒有螢幕也沒關係，只要網路能連上，就可正常運作。順道補充一下，2B那一台的螢幕顯示也是沒有的。

2021年4月7日，星期三

昨天起開始限水，雖然儲備了些許，不過，到現在水龍頭的水還能供水，應該是社區的水塔儲備容量足夠與大家配合省水的結果。

剛剛看了天氣雲圖，希望下個星期就能順利降雨。

2021年3月19日，星期五

USB碟，還是只能用SanDisk，這麼多年下來，還能穩定存取的，都是SanDisk的。其他的，像是T牌，慘不忍睹！

2021年3月11日，星期四

應該是語言邏輯的不一樣，想要找說Google Traslation API已經使用的額度，還真是不好找。

只好把Google Cloud Console的所有配額相關的頁面走馬看花地看過一遍，終於在Cloud Translation API下的「v2 and v3 general model characters」找到，可以看到每天的用量小計圖表，如下圖：

與從資料庫統計的數字是一樣的。

如果懶得去找，就直接把下面的網址帶入專案名稱，即可進入該統計頁面：
https://console.cloud.google.com/apis/api/translate.googleapis.com/quotas?hl=zh-tw&project=這邊帶入您的專案名稱

2021年3月10日，星期三

想要一口氣把Google Translation API支援的語言都上線，而在估算需要的花費時，還是改成分階段上線。

依目前字典檔的大小，一口氣要翻譯剩餘的104個語言，需要近六千萬字元的量，Google Translation API每個月免費的額度是50萬字元，之後的每百萬字元收費美金20美元。如果要一口氣翻譯目前字典檔的近四千筆資料，需要花費新台幣上萬元。

在每個月免費的額度下，104個語言以每個月4個語言的進度來上線，可在2023年5月完成109個語言的支援。

只是不知那個時候，Google Translation API又會支援幾個新的語言呢？

相關連結參考：
Google Translate API 價格表：https://cloud.google.com/translate/pricing?hl=zh-tw
Google Translate API 支援的語言清單：https://cloud.google.com/translate/docs/languages
語文ISO編碼表：https://www.loc.gov/standards/iso639-2/php/code_list.php

2021年3月8日，星期一

昨天把法文翻譯帶入自動上傳的節目名稱與敘述，剛剛把日文翻譯完成。

每天支援一種語言，要把Google Tranlate API支援的109語言完成，要109天。想個可更迅速支援的方法。

2021年3月6日，星期六

節目表的輸入換人，常常意味著要重新修正對接的程式碼！

這個星期，生命電視台的節目上傳，常常中斷，原因是轉入的節目表有問題，不是多了個看似空白但不是空白的符號，就是時間的切割不一樣，使得節目表的日期錯位等諸如此類的問題。

這時候就只好強化修正的程式，修正這些奇奇怪怪的錯誤。

2021年2月9日，星期二

HeidiSQL最新版本的更新，竟然會造成某台伺服器無法連線，真是奇怪的問題！

不過這樣也好，把之前想要寫的字典翻譯更新介面，以Web的方式實做出來，免得再度依賴HeidiSQL的介面。

2021年1月17日，星期日

import ssl

ssl._create_default_https_context = ssl._create_unverified_context

從今年起，python讀取https，需要以上額外的程式碼，解決ssl錯誤的問題。

2021年1月14日，星期四

用來測試YouTube Data API的頻道，

https://www.youtube.com/channel/UCqnqXuCOfUQSRFA0t4pwNlw

2021年1月13日，星期三

昨天(2021-01-12)終於恢復了近三分之一的配額，這次與Youtube Data API Team的溝通真的超不順利！

還好已經先行完成不需要Youtube Data API的上傳方式，已經恢復的配額，調整雲端另一個頻道的使用，暫時夠用。

下次為了避免這樣的問題，一定要分開配額的申請，也要有不依賴配額的運行方式。

2021年1月10日，星期日

緊急寫了一個新增節目表的程式。

2021年1月5日，星期二

今天終於把不用YouTube Data API而能新增語言翻譯的功能完成，免除的配額的限制。

scrcpy作為連接手機與電腦螢幕是一個不錯的選擇，可以使用更大的螢幕來顯示、展示手機的內容。

如果要配合垂直螢幕的話，搭配系統的CTRL+Alt+方向鍵，即可快速切換，或是使用iRotate來支援。

特此紀錄。

2021年1月2日，星期六

新版不依賴Youtube Data API的上傳程式完成了，只不過不是解析通訊協定，而是模擬鍵盤與滑鼠操作瀏覽器，雖然效率無法跟通訊協定的做法相提並論，卻也解決了轉錄檔案上傳的問題。

新的一年，2021到來，願一切都安好，揮別2020/5=404的Error。

2020年12月18日，星期五

不用Youtube Data API，自行解析YouTude URL，果然需要費一番工夫。

2020年12月16日，星期三

從昨天 4:30 起，自動上傳到Youtube的程式就頻頻出現已經超出配額的錯誤，原以為是Google大當機造成配額沒有重置的問題，沒想到，到了今天還是不能使用。

於是登入到Google雲端的後台查看配額，結果發現Youtube的配額竟然被重設為1！只好趕緊重填配額擴增單，希望能趕緊設回原來的額度。

看來是要另找方法來避開這個配額問題，像是自己解析Youtube的檔案上傳，不要使用Youtube Data API。

2020年12月14日，星期一

Youtube掛了！

這幾天把LRA4-5整理了一下，將相關的參數檔案化，這樣一來，想要搬到新電腦上執行，就點單許多，順便把說明書寫下來，作為備忘。

另一方面，也避免依賴Windows環境，將之移植到ubuntu與Raspberry Pi OS，成為新一代的LRA6。

但沒有想到，寫著寫著，測著測著，Youtube竟然掛了！

Yahoo!新聞第一時間就出新聞，https://tw.news.yahoo.com/youtubegmail%E7%AD%89%E7%B6%B2%E7%AB%99%E5%A4%A7%E7%95%B6%E6%A9%9F-%E7%B6%B2%E5%8F%8B%E5%93%80%E8%99%9F%E4%B8%96%E7%95%8C%E6%9C%AB%E6%97%A5%E5%95%A6-120553657.html

2020年12月9日，星期三

一直依賴排排程自動更新的SSL憑證，發生了以下的錯誤，而造成憑證過期了兩天都還不知道：

Attempting to renew cert (byggs.ddns.net) from ... produced an unexpected error: 'ascii' codec can't encode characters in position 156-157: ordinal not in range(128). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/.../fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
 

還好已經有解，參照 https://blog.longwin.com.tw/2019/01/letsencrypt-ascii-codec-decode-fixed-2019/ ，使用下面指令：

sudo grep -r -P '[^\x00-\x7f]' /etc/apache2 /etc/letsencrypt /etc/nginx

再把顯示出來的問題行刪除即可。

今天的Windows 10又自動更新了，結果就是搞得人仰馬翻！

首先，為什麼System要把80 port佔用，先佔先贏，是嗎？結果造成一直服務中的Apache無法啟動，這是哪門子的作法！有遇上相同問題的朋友們，請在管理員模式下，於命令列輸入以下指定：

sc w3svc stop
sc config w3svc start= disabled

如此，就可以正常啟動80 port的伺服器。

另一台機器，就是本來跑得好好的應用程式，突然一直出錯重啟，結果是要設定路徑！

真是夠了，微軟！

ubuntu作業系統版本指令集，

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade

sudo apt autoremove

把 /etc/update-manager/release-upgrades 檔案內的 Prompt=lts 改為 Prompt=normal ，
sudo vi /etc/update-manager/release-upgrades

最後一個指令，開始執行升級，
sudo apt do-releease-upgrade

2020年12月8日，星期二

整理許多舊的USB碟、SD卡等，刪除不必要的資料後，空出了很多個來。

但還是有一些刪不掉的，像是作業系統安裝碟、緊急救援用的開機USB、許久沒用的DOS開機Ghost碟，雖然這個年代已經很久很久都沒用上它們，而基於過去的習慣，還是把這些保留了下來。

2020年11月28日，星期六

Google雲端主機，跑著CentOS 7和MariaDB，但是，MaraiDB一直會有些小問題，靠著額外的程式碼來維持服務的穩定度。

然而，這樣運行到第28天之後，MariaDB的CPU會突然飆上來，佔用了70%以上！手動重啟後，CPU的使用率就恢復正常。不過，已經懶得去找問題點，只好用最土的老方法來解決，也就是排程每天固定的時間點，重新啟動MariaDB的伺服器。

2020年11月18日，星期三

Macbook Air 的電池模組，終於在今天到貨。11/09下單，11/18到貨，跟號稱的5天到貨，還是差了4天。

更換的速度很快，而且也內附兩支起子。基本上，就是拆五角螺絲後，開蓋，再拆六角螺絲，換電池模組。更換之後，再把六角、五角螺絲裝回， 電腦就恢復整常充電的橘燈了。

2020年11月12日，星期四

進入養生模式，開始吃養生食物、運動，拒絕精製食物、低糖，重視花青素、B群維他命攝取。

2020年11月9日，星期一

今天熊熊發現Macbook Air的充電燈常綠，明明已經沒電了！

進入Macos，電池符號竟然出現三角形與驚嘆號，說是要電池要維修。自2012至今，已經過了近八年，電池壽命已盡。

趕緊到露天買了電池模組，到貨後再更換，這幾天，就讓Macbook Air放假。

眼睛有些狀況，祈願大眾得聞此「佛說能淨一切眼疾陀羅尼咒」，生生世世眼光明。
https://youtu.be/3aw6cJaF5fI

2020年11月5日，星期四

如果有烹飪用的小秤，那麼就可以用如下的份量，煮出好吃的飯(僅測試PHILIPS的電子壓力鍋、7-11可以買到的御膳米、以3M濾過的水)：

1.米300公克。(這邊考慮兩人的份量)
2.水500公克。(注意洗完米之後，米會有水附著，須將附著的水列入考慮)
3.鹽0.5公克。
4.橄欖油(或其他的油)0.5公克。
5.醋0.5公克。

如果需要飯再更軟些，水就稍微加多些；要硬些，水就少一些，因米的種類而會有不同。(不同品牌的電子鍋或煮飯的方式也會影響，基本上都是調整水的多寡，或是預泡，就事先把米以水浸泡10到20分鐘後，再煮。)

或許哪一天，在big data與machine learning等的加持下，可以自動識別或學習，煮出最好吃的飯。

2020年11月4日，星期三

統計與機器學習的目的不同，統計偏重因果關係的解釋，而機器學習則是預測的結果。個人覺得這篇文章介紹的很好，https://buzzorange.com/techorange/2019/05/02/difference-between-statistics-and-machine-learning/ 。

以前統計幾乎靠SPSS，時至今日，可以選用更開放的R，GTW Blog有一系列的教學文章，很值得參考。