别再忍受网抑云欺压了,用起外网IP来搭建自己的私有云音乐吧

作者:V君 发布于:2022-3-14 11:01 Monday 分类:我的应用

TL;DR for 立即想拿来用的人:[ 下载 | 源代码 ]

1)解压,用文本编辑器修改配置文件 config.json
 ◆ListenPrefix 用来配置监听的IP和端口,格式是 http://+:12345
  若要指定监听的网卡,将加号改成对应网卡IP即可
 ◆Libraries 里面每一项作为音乐库定义,Key是显示名称,Value是物理路径
  音乐库目录结构
  $/专辑
    cover.jpg
    01.flac
    02.flac
    03.flac
    /BK
      scan1.png
      scan2.png
      scan3.png
    /AAC_
      01.m4a
      02.m4a
      03.m4a
 ◆MediaFilePattern、BkFilePattern 保持默认即可
2)然后直接双击 FNZCM.ConHost.exe 启动,启动后扫描媒体库获取元数据生成列表
在浏览器打开监听的地址就可以浏览媒体库、专辑、音轨、BK,音轨页面可以在线播放
当文件发生变化时,点击首页底部的 Reload 来刷新媒体库
接着就可以将M3U8链接甩给播放器 APP 在线播放
X)进阶:如果嫌FLAC使用流量太多,肉疼的话还可以批量生成高品质AAC(m4a)
(文件大小缩减到一半以下,音质损失可忽略不计)
只是目前配套的批量转换工具还没有发布直接可用的版本
感兴趣的小伙伴可以阅读源代码了解使用方法,自己编译一个来用)

简单扯一扯缘起

由于无法忍受网抑云肆意下架、移除歌单中的收藏项,而且自己上传一些私有音乐,相似但不同的变异版本它识别得乱七八糟,我决定丢掉它找别的方法听歌。(其实最无法忍受的是吃相太难看)

起初回到原始的下载 FLAC 放到电脑或者手机直接播放,在电脑直接播放本地(局域网共享)文件还行,只是手机端就没这么方便了,还得考虑存储空间,得想办法随时随地直接播放家里的媒体库才行。

简单扯一扯开发感想

碍于爱折腾的个性,首先不使用现成的产品,不管你免费与否、开源与否❌

私有云音乐的本质就是一个流媒体服务器,如果是局域网,直接走共享即可,但是出门在外还想用家里的音乐库,这就得想想办法了。

最开始的步伐迈开的太大,想做一个大而全的网页版,扯蛋不说一直没整出一个像样的东西来

后来想起音乐播放 APP 可以载入 M3U8 格式的列表,这样就不用自己造界面的轮子了,咱可以基于静态目录结构实现随时随地用 VLC 之类的 APP 在线播放。用播放器的好处还有兼容性高,已知一些高规格的FLAC文件无法在浏览器播放,而 VLC 能轻松播放。

于是这个简化版的私有云音乐就出来了,它还有一个接地气的内部名称:“土炮云”

标签: 软件开发 C# HTTP 音频 传输协议 流媒体

评论(1) 引用(0) 浏览(232)

自己动手做一个屏幕扩展APP(?)让老平板作为扩展屏幕

作者:V君 发布于:2021-4-12 23:25 Monday 分类:我的应用

这次先扯一句再开始:对标题中问号的解释,由于这玩意儿不仅仅是个APP,也支持Web方式,而且还有PC桌面端,姑且就叫做APP(?)吧 乂目

TL;DR [ 下载 ][ 源代码 ]

效果:将指定窗口截图并以以下方式广播,可以将移动设备或者另一台电脑作为扩展屏幕
 - HTTP、MjpegOverHttp(?实为 PNG in multipart/x-mixed-replace)
 - Socket(APP)
环境:
 - PC端基于 .NET Framework 4.0 编译,未在低于 Win 10 环境下测试
 - 为不支持 MjegOverHttp 的旧版本 Android 平板做了 APP,已在 Android 3.0.1 上测试
用法:
 1. 在PC端启动 ScreenExtender.exe 检查监听IP和端口
 2. 点击Listen启动监听,如果弹出防火墙,请允许
 3. 点击 Add 按钮,点击要添加窗口,添加完之后可在预览画面上拖动
 4. 在浏览器访问监听IP和端口
  - http://192.168.x.x:61234/frame 获取当前帧
  - http://192.168.x.x:61234/ 使用性能较低的画布方式轮询绘制帧
  - 较新的设备(浏览器)可以访问 http://192.168.x.x:61234/mjpeg 可获得更高性能
 A. 为老设备准备的Android端
  - 安装启动后会弹出输入IP和端口的输入框,输入正确IP和端口
  - 触摸OK即可开始工作,APP会记住最后一次使用的IP和端口
限制:指定的窗口不能最小化,可以被其他窗口遮住在后台运行

稍微扯扯:

尽管目前用了5块1080p显示器,但还是不能满足需求,仍有一些需要监视的东西没能摆下,手里虽然还有闲置的显示器,但电脑桌已经没有地方放第六块显示器了,大概只能钉在墙上了吧……

想起还有一块闲置的老Android平板,那就折腾折腾把他当一块扩展屏幕来用吧。起初用了第三方APP,发现平板的Android版本太低,而且找不到包可以刷(我不会说经历多次变砖然后救回来,直到放弃治疗的)。

想起早些年玩浏览器视讯直播的 MJPEG 了,但遗憾的是老平板的Android版本只有3.0.1,连MJPEG都不支持(然而还好支持画布,但性能太低了),那就专门给它做了个APP,用着效果还不错。

对于版本较新的移动设备,可以直接用浏览器访问 mjpeg 方式

标签: 软件开发 C# Winform HTTP Android

评论(1) 引用(0) 浏览(848)

通过WebSocket隧道,尝试将ASP.NET网站空间当作VPS来使用

作者:V君 发布于:2021-1-17 11:50 Sunday 分类:折腾手记

先上 PoC源代码 再开始扯,这次不是着重解决某个问题,而是尝试确定某种可能性。

以前使用过 C9.io 提供的免费在线开发环境来搞各种事情,包括正常上网,无非是利用 Web Sockets 建立隧道,然后配合客户端连接到在上面运行各种应用程序。
现在C9已经被收购且停止免费了,那就公开来说吧w

这次也不例外,只不过花了点钱搞了个支持 ASP.NET 4.5+ 的网站空间,然后在上面搞类似的事情。

基础设施 -- WebSocket 转 TCP 模块

首先要使用 WebSocket 来建立一条隧道,要求网站空间支持且启用 WebSocket,不然没法整。这里有个未经优化,但还能凑合着用的例子,只要挂在 HttpModule 中 HttpApplication 的 PostMapRequestHandler 事件,填好参数就能吃。

折腾1 -- SSH 终端

略去寻找绿色 SSH 服务端的辛酸过程,时间直接转到发现 FxSsh 这个纯托管实现的服务端。这里要分成两个部分来扯,分别是使用基于 ConPTY 的 MiniTerm 和兼容低版本 Windows 的简单兼容实现。由于 FxSsh 主要实现的是 SSH 协议通道,服务端的终端并没有适配,尽管源代码中带了个名为 MiniTerm 的 DEMO 来适配到较新系统的 ConPTY。

第一部分:基于 MiniTerm 的实现。原版的 MiniTerm 虽然导入了 ResizePseudoConsole 这个 API 但并没有使用。而且由于 NuGet 上的 FxSsh 不是最新版,没有窗口大小变更事件的支持。 因此我把他们全都拷贝到自己的项目中并注明来源了。在此之上再加以修改 MiniTerm 使窗口大小变更事件适配到 MiniTerm 的实现。目前并没有发现太多问题。有点小遗憾的是 MiniTerm 使用的 ConPTY 功能是 Windows 10 近些年的更新才引入的,因此许多网站空间的系统都不支持,会报「在 kernel32 中找不到 CreatePseudoConsole 入口」的错误,因此我准备了另一个方案,见接下来的第二部分。

第二部分:另行实现一个兼容低版本 Windows 的控制台进程适配。在项目中起名为 EasyTerminal。起初简单将控制台进程的标准输入输出还有错误输出重定向到 SSH 通道,然鹅,回车键不起作用,而且不回显。将回车键拦截下来,改成 StandardInput.WriteLine 调用,总算是能满足最基本的需求。尽管还是没有实时回显,得按下回车键之后才显示出来,功能按键和窗口大小什么的更无从说起。目前仍在使用零碎的时间持续摸索(咕XD)…

折腾2 -- 正常上网 将网站空间当作 V2 服务端使用

编译部署这个项目,然后将 V2 的两个 exe 和配置文件丢进 App_Data 目录,然后使用 WS 隧道连接到监听的 URL,最后在 V2 客户端指向 WS 隧道客户端,这时候就能吃了。分配了较大的缓冲区大小,这应该能有效减少损耗,如果网速慢,你需要测一下空间到你的网速。

不水。

标签: 软件开发 个人服务器 C# HTTP Web技术 传输协议 Windows .NET IIS WebSocket

评论(0) 引用(0) 浏览(320)

自己动手用C#写无盘引导服务

作者:V君 发布于:2020-3-5 22:18 Thursday 分类:我的应用

发表一下最近折腾的东西,还没折腾完,因此不太TL;DR,再扯扯 (pia

[ 源代码 ] 目前只做了 DHCP、TFTP 和 iPXE 用的 HTTP 脚本服务。由于只是勉强能用,并不友好,因此尚未提供直接可用的二进制文件

— 使用方法:开始 —

将源代码弄下来,还原 NuGet 包,编译。导航到解决方案根目录的 bin 文件夹,我把它们的输出全都指向这里以方便编辑配置文件。

  • 编辑 DHCP 配置文件,正确设置监听地址
  • 编辑 TFTP 配置文件,正确设置监听地址、正确设置根路径
  • 编辑 HTTP 配置文件,正确设置监听前缀

源代码和下面的描述已经差别很大,DHCP池已经实现,等什么时候蛋疼再回来扯扯(被打x

启动这三者,不要忘记调整防火墙,插好网线启动从机,设置好 BIOS 使其从 PXE 启动。这时候还不能顺利引导,DHCP 服务会在 DhcpEntries 文件夹会自动生成 MAC 地址的对应的 json 配置文件,修改 default 配置文件设置除了IP之外的字段,如子网掩码、网关、DNS、启动文件名,然后再在对应 MAC 的配置文件里面指定 IP 地址,将 Enable 字段置为 true。注意字段 Enable 对 Default 配置文件无效。这时候从机应该能分配到 IP 地址,然后去 TFTP 获取启动文件了。本例使用 iPXE 作为引导。

本例提供的 iPXE 嵌入了【再次获取 DHCP 并将启动文件名作为 chain 目标】,可以将 chain 指定为 HTTP 的 URI,从服务器吐出脚本来实现动态执行。通过 iPXE 发出的 DHCP 请求带有 UserClass 字段,会自动生成配置文件,可以另外指定启动文件名为 HTTP 网址。

配置文件的叠加顺序为:Default → Default-【UserClass】 → MAC → MAC-【UserClass】。值为 null 的字段将被忽略。接下来就可以去 IpxeScripts 文件夹配置 iPXE 脚本了。引导部分到此结束,接下来的步骤是连接到存储服务器、启动系统了。

— 使用方法:结束 —

— 扩充:开始 —

常见的的无盘使用 iSCSI 方式连接到服务器,详细用法请参考示例或查阅 iPXE 使用手册。iSCSI 服务端可以使用 StarWind 或者 TalAloni/iSCSIConsole 亦或者是 我的fork。 我在 TalAloni 的基础上增加了大容量、可加载 RamDisk 和类似 StarWind 的 ibv 支持。能从一个镜像中创建分支快照,能让多台机器同时使用,有点像 VMware 的链接克隆。

— 扩充:结束 —

— 扯扯:开始 —

刚刚开始的时候我用了 TFTPD32、Grub4Dos、固定脚本的 iPXE、还有 Star wind。由于效果很不理想,得想办法解决。 TFTPD32 的毛病:分配IP地址时间较长、TFTP经常抽筋;StarWind 的毛病:服务进程经常崩溃;尽管 TalAloni 的实现很稳定,但它的界面简直就是个 DEMO,每次打开都要配置……后来深入了解 DHCP 协议,发现可以它很简洁,可扩展性又强,再了解 iPXE 动态脚本,这套组合拳就打出来了。

虽然 DHCP 和 TFTP 的协议都挺好搞,但 iSCSI 协议就复杂了,想让指定的 Target 能根据客户端 iqn 自动创建快照, 实现不同机器连接到同一个 Target,却是各自使用自己的快照,目前还在咕咕咕(

— 扯扯:结束 —

标签: 软件开发 C# HTTP PXE DHCP TFTP iPXE

评论(2) 引用(0) 浏览(1403)

尝试在Windows NT6+上免驱实现FUSE

作者:V君 发布于:2017-9-22 20:18 Friday 分类:折腾手记

■前言  (这次不是解决问题,因此没有TLDR(´∀((☆ミつ)


首先简单解释一下 FUSE 的定义:

在用户空间实现的虚拟文件系统, 能够让标准文件系统API访问,

只是某个路径在应用程序的控制之下, 还没到达虚拟块设备的级别.


FUSE 能够实现许多有趣的功能, 比如挂载压缩包, FTP, MTP, 甚至 Ramdisk 都能实现.

在 linux 实现 FUSE 可以说是相当容易,

由于 linux 可以把 FUSE 功能集成到内核, 随便 mount 就可以了.

然而 Windows 内核并没有这样的功能,

只能以虚拟设备来创建虚拟盘符或挂载到 NTFS 装入点亦或者建立目录符号链接.

 

现状


在 Windows 实现 FUSE 通常需要虚拟驱动器来实现, 这需要驱动程序来支持.

现成的软件有

1)免费的 WinMount(生死未卜)

2)收费的 NetDrive.

它们都是封装好的产品, 用户不能定制自己的功能.

可以自己实现接口的驱动组件有

1)开源的 Dokan(貌似不太稳定)

2)开源的 WinFsp(没用过,无法评论)

3)死贵死贵的 CBFS.

早些年把玩过Dokan, 虽然提供了.NET的接口, 且实现难度还不算高.

假如接口实现得不稳定, 没妥善处理好异常就可能会引发蓝屏, 这也就是本文的初衷.

-- 不使用驱动来实现 FUSE , 就算接口实现得再糟糕也不会把系统搞崩溃.

 

摸索


稍稍有点经验的 Windows 用户都知道,

资源管理器可以直接访问FTP或多媒体设备存储(MTP/PTP)

可以把路径以文件夹的形式图形化呈现, 

然而这些路径并不能够使用标准文件系统 API 来放访问,

不能用 WindirStat 来统计 MTP 上的文件夹占用情况.

尽管资源管理器双击能打开这些路径中的文件,

其实背地里还是先复制到临时文件再调用关联的应用程序去打开.

 

其实 Windows 还是可以不依赖驱动就能实现 FUSE 的.

目前发现了两种方法, 尽管都是利用网络共享绕一圈, 还蛮折腾的:

1)基于 HTTP 的WebDAV 协议

 在一次折腾如何在安桌手机 USB 的 MTP 模式使用 WinDirstat 的过程中

 发现了 WebDAV 共享 APP.

 安装并启动之后, 按照步骤创建映射盘符, 能被 WinDirstat 访问了.

 咕狗了解到是基于 HTTP 的共享协议.

 (这是WebDAV over WIFI, 这已经和 MTP 没关系了, 不过下文还是会和MTP有关系)

 这才发现 Windows 还有这种共享方式, 支持标准文件系统 API, 

 只是实现机制略坑, 性能略糟糕.

2)Samba 局域网共享

 不解释太多也不会被打 (´∀((☆ミつ

 需要实现一个 SMB 服务端, 还要战 445 端口. 战? 不是占? YES, 稍后娓娓道来.

 

尝(zhe)试(teng)


□WebDAV -- 这货是真FUSE, 只是 Windows 实现机制太坑人


知道这货基于 HTTP 之后, 当然就是去找找看有没有人已经做成类库, 而不是先自己啃RFC.

放狗出去找到两个类库, 分别是 SF 上的 WebDAV.NET 服务框架 和 GitHub 上的 WebDAVSharp.

这次选择了后者, 只要按接口做实现, 就可以达到目的, 咋一看还挺完善的, 只是性能有点慢.

即使用内存来实现后端文件存储, 访问速度也和硬盘差不多,

监视性能才发现, 原来 Windows 在背后依然用临时文件的方式暂存 WebDAV 上面的文件, 

只是重定向了一下文件系统. 难怪这么慢, 这 FUSE 虽然是真货, 但却掺了水.

你可以把它的临时目录(↓)链接到 RAMDISK 以提升性能, 此目录必须存在才能正常操作文件.

C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV\

只不过这样就失去了用 WebDAV 实现 RAMDISK 的意义, 只能用作简单 FUSE 玩玩.

顺便再贴一个之前还没了过背后原理, 仍未知性能坑时, 实现MTP2DAV

 

Samba -- 战445端口要不要太折磨人?


非常幸运地找到最近 TalAloni 用 .net 实现且一直在维护的 Samba 服务端的库 SMBLibrary.

看了下介绍, 确实有提到可以实现虚拟文件系统. -- 只是 445 被 Windows 锁死, 需要一战.

除非禁用 Server 服务, 否则全部适配器的 445 端口将不可用...见爆栈.

尝试了许多诸如增加虚拟适配器的 trick 做法, 然而并没有设么卯月...

停止 Server 服务之后还不行, 445 仍然会被 System 占用, 需要重启...

那就只能彻底禁用了.禁用了 Server 服务并重启之后, 445 端口总算可用.

把内置的目录共享跑起来, 效果还挺理想, 性能相当不错, 看了一下接口并不是很复杂.

就简单做了个后端用内存支撑的 RamDisk 实现, 然而并不是很理想.

-- 非常不稳定, 常规操作下会出现各种错误, 看来是接口适配的不太妥哇...

总之, 这种 Samba 的方式是可行的.

只是稍稍麻烦点, 无论是从禁用 Server 服务还是实现接口上来看...


■结论


WebDAV 可以用来实现简单的 FUSE, 无法考虑性能.可以用 RamDisk 稍稍提升一下.

Samba 性能相当好, 接口略复杂, 目前还没啃透 (´∀((☆ミつ

标签: C# Winform NAS HTTP 传输协议 FUSE VFS Windows

评论(0) 引用(0) 浏览(2472)

Powered by emlog 去你妹的备案 sitemap