![]() |
樂園日記
|
![]() |
Youtube頻道新增八個語文翻譯,西班牙文、德文、泰文、越南文、韓文、義大利文、荷蘭文、印尼文,目前總計更支援13個語文。
下個月預備支援以下八個語文:馬來文、高棉文、阿拉伯文、瑞典文、尼泊爾文、挪威文、俄文、孟加拉文。
![]() |
罕見發生磁碟機檔案錯亂的問題,把SD卡拔除來,在Windows下修復之後,即恢復正常運行。
這個問題,早在199X年,常常發生,三不五時就要修復一下,沒想到在2021這個檔案系統已經不知道發展到何種規格的年代,還是發生了這樣的問題。
本以為是樹莓派機子出了問題,因為連到HDMI的電視,沒有任何螢幕顯示!把SD卡拿下來,拿到Windows下讀,還可讀出來,只不過提示說,檔案系統可能發生問題,需要修復。
至於為什麼沒出現螢幕,這個就不再繼續往下追了,因為另一台4B的顯示是正常的,3B的這台,用在伺服器上,沒有螢幕也沒關係,只要網路能連上,就可正常運作。順道補充一下,2B那一台的螢幕顯示也是沒有的。
![]() |
昨天起開始限水,雖然儲備了些許,不過,到現在水龍頭的水還能供水,應該是社區的水塔儲備容量足夠與大家配合省水的結果。
剛剛看了天氣雲圖,希望下個星期就能順利降雨。
![]() |
USB碟,還是只能用SanDisk,這麼多年下來,還能穩定存取的,都是SanDisk的。其他的,像是T牌,慘不忍睹!
![]() |
應該是語言邏輯的不一樣,想要找說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=這邊帶入您的專案名稱
![]() |
想要一口氣把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
![]() |
昨天把法文翻譯帶入自動上傳的節目名稱與敘述,剛剛把日文翻譯完成。
每天支援一種語言,要把Google Tranlate API支援的109語言完成,要109天。想個可更迅速支援的方法。
![]() |
節目表的輸入換人,常常意味著要重新修正對接的程式碼!
這個星期,生命電視台的節目上傳,常常中斷,原因是轉入的節目表有問題,不是多了個看似空白但不是空白的符號,就是時間的切割不一樣,使得節目表的日期錯位等諸如此類的問題。
這時候就只好強化修正的程式,修正這些奇奇怪怪的錯誤。
![]() |
HeidiSQL最新版本的更新,竟然會造成某台伺服器無法連線,真是奇怪的問題!
不過這樣也好,把之前想要寫的字典翻譯更新介面,以Web的方式實做出來,免得再度依賴HeidiSQL的介面。
![]() |
import ssl
ssl._create_default_https_context = ssl._create_unverified_context
從今年起,python讀取https,需要以上額外的程式碼,解決ssl錯誤的問題。
![]() |
用來測試YouTube Data API的頻道,
https://www.youtube.com/channel/UCqnqXuCOfUQSRFA0t4pwNlw
![]() |
昨天(2021-01-12)終於恢復了近三分之一的配額,這次與Youtube Data API Team的溝通真的超不順利!
還好已經先行完成不需要Youtube Data API的上傳方式,已經恢復的配額,調整雲端另一個頻道的使用,暫時夠用。
下次為了避免這樣的問題,一定要分開配額的申請,也要有不依賴配額的運行方式。
![]() |
緊急寫了一個新增節目表的程式。
![]() |
今天終於把不用YouTube Data API而能新增語言翻譯的功能完成,免除的配額的限制。
scrcpy作為連接手機與電腦螢幕是一個不錯的選擇,可以使用更大的螢幕來顯示、展示手機的內容。
如果要配合垂直螢幕的話,搭配系統的CTRL+Alt+方向鍵,即可快速切換,或是使用iRotate來支援。
特此紀錄。
![]() |
新版不依賴Youtube Data API的上傳程式完成了,只不過不是解析通訊協定,而是模擬鍵盤與滑鼠操作瀏覽器,雖然效率無法跟通訊協定的做法相提並論,卻也解決了轉錄檔案上傳的問題。
新的一年,2021到來,願一切都安好,揮別2020/5=404的Error。
![]() |
不用Youtube Data API,自行解析YouTude URL,果然需要費一番工夫。
![]() |
從昨天 4:30 起,自動上傳到Youtube的程式就頻頻出現已經超出配額的錯誤,原以為是Google大當機造成配額沒有重置的問題,沒想到,到了今天還是不能使用。
於是登入到Google雲端的後台查看配額,結果發現Youtube的配額竟然被重設為1!只好趕緊重填配額擴增單,希望能趕緊設回原來的額度。
看來是要另找方法來避開這個配額問題,像是自己解析Youtube的檔案上傳,不要使用Youtube Data API。
![]() |
Youtube掛了!
這幾天把LRA4-5整理了一下,將相關的參數檔案化,這樣一來,想要搬到新電腦上執行,就點單許多,順便把說明書寫下來,作為備忘。
另一方面,也避免依賴Windows環境,將之移植到ubuntu與Raspberry Pi OS,成為新一代的LRA6。
但沒有想到,寫著寫著,測著測著,Youtube竟然掛了!
![]() |
一直依賴排排程自動更新的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
![]() |
整理許多舊的USB碟、SD卡等,刪除不必要的資料後,空出了很多個來。
但還是有一些刪不掉的,像是作業系統安裝碟、緊急救援用的開機USB、許久沒用的DOS開機Ghost碟,雖然這個年代已經很久很久都沒用上它們,而基於過去的習慣,還是把這些保留了下來。
![]() |
Google雲端主機,跑著CentOS 7和MariaDB,但是,MaraiDB一直會有些小問題,靠著額外的程式碼來維持服務的穩定度。
然而,這樣運行到第28天之後,MariaDB的CPU會突然飆上來,佔用了70%以上!手動重啟後,CPU的使用率就恢復正常。不過,已經懶得去找問題點,只好用最土的老方法來解決,也就是排程每天固定的時間點,重新啟動MariaDB的伺服器。
![]() |
Macbook Air 的電池模組,終於在今天到貨。11/09下單,11/18到貨,跟號稱的5天到貨,還是差了4天。
更換的速度很快,而且也內附兩支起子。基本上,就是拆五角螺絲後,開蓋,再拆六角螺絲,換電池模組。更換之後,再把六角、五角螺絲裝回, 電腦就恢復整常充電的橘燈了。
![]() |
進入養生模式,開始吃養生食物、運動,拒絕精製食物、低糖,重視花青素、B群維他命攝取。
![]() |
今天熊熊發現Macbook Air的充電燈常綠,明明已經沒電了!
進入Macos,電池符號竟然出現三角形與驚嘆號,說是要電池要維修。自2012至今,已經過了近八年,電池壽命已盡。
趕緊到露天買了電池模組,到貨後再更換,這幾天,就讓Macbook Air放假。
眼睛有些狀況,祈願大眾得聞此「佛說能淨一切眼疾陀羅尼咒」,生生世世眼光明。
https://youtu.be/3aw6cJaF5fI
![]() |
如果有烹飪用的小秤,那麼就可以用如下的份量,煮出好吃的飯(僅測試PHILIPS的電子壓力鍋、7-11可以買到的御膳米、以3M濾過的水):
1.米300公克。(這邊考慮兩人的份量)
2.水500公克。(注意洗完米之後,米會有水附著,須將附著的水列入考慮)
3.鹽0.5公克。
4.橄欖油(或其他的油)0.5公克。
5.醋0.5公克。
如果需要飯再更軟些,水就稍微加多些;要硬些,水就少一些,因米的種類而會有不同。(不同品牌的電子鍋或煮飯的方式也會影響,基本上都是調整水的多寡,或是預泡,就事先把米以水浸泡10到20分鐘後,再煮。)
或許哪一天,在big data與machine learning等的加持下,可以自動識別或學習,煮出最好吃的飯。
![]() |
統計與機器學習的目的不同,統計偏重因果關係的解釋,而機器學習則是預測的結果。個人覺得這篇文章介紹的很好,https://buzzorange.com/techorange/2019/05/02/difference-between-statistics-and-machine-learning/ 。
以前統計幾乎靠SPSS,時至今日,可以選用更開放的R,GTW Blog有一系列的教學文章,很值得參考。
過往的日記本頁執行共花了: 0.034319877624512秒