事象の水平線

横を無理やり伸ばしたので、デザインがおかしいけど、気にしない。完璧に時代に取り残されたHTMLをいまさらいじるのがめんどくさい。個人的ブックマーク代わりなメモ書きブログ。

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PageTop
2018年12月 4K8K本放送開始らしく、今までのFHD(フルハイビジョン=2K)放送の帯域を削って4K8Kに割り当てるべく、再編成だそうだ。

BS右旋の放送の帯域再編(周波数再編成)について

で、対処法を個人用メモ
recpt1が影響を受けるので、recpt1を再度コンパイルする。
その際、
Mercurial > pt1
の最新のパッチで対応できる。(メンテナンスありがとうございます。)

で、おわり。


なのだけど、
ストリーム配信のhttp版パッチ(参照先を後述)を当てているので、
最新のMercurial > pt1 のzipを持ってきて(Mercurial は入れてない。)http版パッチをそのまま当てると、最新のrecpt1がどうやら変数名を変えてるらしく、コンパイルでエラーが出てうまくいかない。
たしか、dec が decodeになってる。のと、argの型が合わないとか言われる。
無理やり合わせてコンパイルしたら、録画はできるが、http配信ができない。当然か。

ので、以前のrecpt1のソースを使い、それに新しいrecpt1のpt1_dev.hだけを置き換えてコンパイルすることにした。

EPGrecUNAは自動で対応してくれる。ので、まぁ、EPGを自動で取得するタイミングでなんかしてくれる。んだろう。実際、自動で変わったっぽい。

<<参考>>
recpt1 http版 怒られながら入れてみる
recpt1 http版 プロセスが落ちたときにphpで手動でブラウザからexecする
CentOS6.5 に epgrec UNA

スポンサーサイト

PageTop
WannaCry 対策としてSMB1.0の無効化
<<参考>>SMB1.0クライアントを無効にする方法

で、SMB1.0を無効にしたらCentOS6.5のNASにつながらなくなった。
CentOS6.5のSambaは
# smbd -V
Version 3.6.9-167.el6_5
バージョン3.6だけど、なんで?

結論
/etc/samba/smb.conf
security = share
...
guest ok = yes
guest only = yes

とかで、Lan内でだれでも繋がってたけど、
<<参考>>Samba 3.6.0のSMB2ではまる
以下にしたらつながった
max protocol = SMB2
...
security = user

で、ユーザー、パスワードが必要になった。けど、ユーザーはOSのアカウントとは別なのね。
<<参考>>smbpasswd - samba パスワードの変更
smbpasswd -a UserName

で、ユーザーを登録したらOK。

Windows7、10とかは資格情報マネージャーでユーザー、パスワードが保存されて、毎回入力しなくていいのね。

こんなんでも6時間もハマった
これって、以前はSMB1.0でつながってたってこと?

PageTop
個人用メモ。

解決しないけど、少しは直る。(けど、IME2010の変換頭悪いんですけど…・)

アクテイブウィンドウが最前面に来ないのが解決した-モエ エ シャンドン

PageTop
Apk Expansion を使い、zipの中身をcontentProvider経由でgoogleのライブラリの『\sdk\extras\google\market_apk_expansion\zip_file』で使うと、StrictModeで
 A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:184)
at java.io.RandomAccessFile.(RandomAccessFile.java:128)
at com.android.vending.expansion.zipfile.ZipResourceFile.addPatchFile(ZipResourceFile.java:275)
at com.android.vending.expansion.zipfile.ZipResourceFile.(ZipResourceFile.java:189)
at com.android.vending.expansion.zipfile.APKExpansionSupport.getResourceZipFile(APKExpansionSupport.java:67)
at com.android.vending.expansion.zipfile.APKExpansionSupport.getAPKExpansionZipFile(APKExpansionSupport.java:77)
at com.android.vending.expansion.zipfile.APEZProvider.initIfNecessary(APEZProvider.java:154)
at com.android.vending.expansion.zipfile.APEZProvider.openAssetFile(APEZProvider.java:175)
at android.content.ContentProvider.openTypedAssetFile(ContentProvider.java:1458)
at android.content.ContentProvider.openTypedAssetFile(ContentProvider.java:1524)
at android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:355)
at android.content.ContentResolver.openTypedAssetFileDescriptor(ContentResolver.java:1089)
at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:929)
at android.content.ContentResolver.openInputStream(ContentResolver.java:654)

とか言われる。

で、結論
zip_fileのZipResourceFileクラスの以下のメソッドで
RandomAccessFileがcloseされていないのが原因
   void addPatchFile(String zipFileName) throws IOException
{
File file = new File(zipFileName);
RandomAccessFile f = new RandomAccessFile(file, "r");
long fileLength = f.length();
~~~~~

ので、
    void addPatchFile(String zipFileName) throws IOException
{
RandomAccessFile f = null;
try{
File file = new File(zipFileName);
f = new RandomAccessFile(file, "r");

~~~~~~~~~~~~~~~~~
}finally{
try{ f.close(); }catch(Exception e){ }
}

}

よくあるように閉じるようにして、終了。

APK Expansion - APKExpansionSupport.getAPKExpansionFiles の bug
といい、なんか罠多すぎるよ。

PageTop
APK Expansion でうまく動かないと思ったら、googleのソースにバグがあったのでメモ。

APK Expansion に関するwhat? how? は以下参照
Expansion Filesについて(1) - obb作成編 - キノコの自省録
Expansion Filesについて(2) - obb利用編 - キノコの自省録
Expansion Filesについて(3) - obbダウンロード編 - キノコの自省録
[android] APK Expansion Files | Drowsy Dog's Diary
[android] APK Expansion Files(2) | Drowsy Dog's Diary
Androidの拡張ファイルから動画を再生する | Kludge factory
APK Expansion Files – チラシの裏

jobb を使って作ったobbはマウントできない環境があるとかないとか。
で、無圧縮zipがいけるぽいのでやってみた。

で、LibraryとしてReferする以下のコードがbugっぽい。

public class APKExpansionSupport {
// The shared path to all app expansion files
private final static String EXP_PATH = "/Android/obb/";

static String[] getAPKExpansionFiles(Context ctx, int mainVersion, int patchVersion) {
String packageName = ctx.getPackageName();
Vector ret = new Vector();
if (Environment.getExternalStorageState().equals(
Environment.MEDIA_MOUNTED)) {
// Build the full path to the app's expansion files
File root = Environment.getExternalStorageDirectory();
File expPath = new File(root.toString() + EXP_PATH + packageName);

// Check that expansion file path exists
if (expPath.exists()) {
if ( mainVersion > 0 ) {
String strMainPath = expPath + File.separator + "main." + mainVersion + "." + packageName + ".obb";
File main = new File(strMainPath);
if ( main.isFile() ) {
ret.add(strMainPath);
}
}
if ( patchVersion > 0 ) {
String strPatchPath = expPath + File.separator + "patch." + mainVersion + "." + packageName + ".obb";
File main = new File(strPatchPath);
if ( main.isFile() ) {
ret.add(strPatchPath);
}
}
}
}
String[] retArray = new String[ret.size()];
ret.toArray(retArray);
return retArray;
}
これ、コードをコピペして書き換え忘れちゃいました。じゃないんでしょーか。
patch がわのFile main は名前だけの問題なんで実質関係ないですが。

これによって、バージョン違いのpatchからデータが取り出せず。という状況になりました。
で、赤文字のint mainVersion を patchVersion へ書き換えて動いたわけですが。
ちなみに、mainとpatchと両方ともzipファイルで無いとzipファイルじゃないよとか言って落ちます。

ちなみにちなみに、Accessing expansion patch files bug (and solution)なんてのが2014年に書かれているけど。直ってないんですね。いまだにEclipseでやってるんで、AndroidStudioだとSDK直ってるとかないですよね?

PageTop
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。