樂園日記
相關資料統計表
向量浮屠
大航海時代online手札
2021年4月14日,星期三
1:35:1

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

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


2021年4月8日,星期四
17:30:20

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

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

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

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


2021年4月7日,星期三
18:29:47

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

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


2021年3月19日,星期五
21:35:9

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


2021年3月11日,星期四
16:13:57

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

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

Cloud Traslation API 用量統計圖表

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

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


2021年3月10日,星期三
17:20:33

想要一口氣把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日,星期一
18:10:14

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

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


2021年3月6日,星期六
18:53:11

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

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

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


2021年2月9日,星期二
22:41:52

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

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


2021年1月17日,星期日
12:3:44

import ssl

ssl._create_default_https_context = ssl._create_unverified_context

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


2021年1月14日,星期四
18:5:0

用來測試YouTube Data API的頻道,

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


2021年1月13日,星期三
14:36:19

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

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

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


2021年1月10日,星期日
17:12:28

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


2021年1月5日,星期二
20:56:41

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

1:14:3

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

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

特此紀錄。


2021年1月2日,星期六
20:55:20

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

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

 


2020年12月18日,星期五
20:18:39

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


2020年12月16日,星期三
17:8:47

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

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

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


2020年12月14日,星期一
20:16:7

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日,星期三
23:15:54

一直依賴排排程自動更新的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

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

22:35:44

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

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

sc w3svc stop
sc config w3svc start= disabled

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

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

真是夠了,微軟!

15:38:12

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日,星期二
3:6:19

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

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


2020年11月28日,星期六
18:10:28

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

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


2020年11月18日,星期三
18:57:3

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

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


2020年11月12日,星期四
0:17:25

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


2020年11月9日,星期一
22:10:17

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

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

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

20:17:9

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


2020年11月5日,星期四
12:8:4

如果有烹飪用的小秤,那麼就可以用如下的份量,煮出好吃的飯(僅測試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日,星期三
18:33:30

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

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

過往的日記

本頁執行共花了: 0.023331880569458秒