Category Archives: personal

Got NTKTV Running in Linux!

I’m currently studying Japanese. I’m nowhere near good enough yet to understand Japanese media without subtitles, but I still like trying to watch in hopes that I’ll pick up on a few words or something.

I came across an archive containing what seems to be an unrestricted version of NTKTV, containing access to several channels. It’s coded in Java also, but it expects Windows, Command Prompt, and Windows Media Player to be present.

When I initially tried running the .jar file for the TBS channel on Linux, it refused to download the video. I couldn’t quite figure out why this was happening, so I figured I would try a different approach. I used some program to decompile the .jar, and after a little bit of searching, I eventually found a URL.

The URL in the TBS channel lead to http://61.172.249.113:8080/jptv24vod/TBS01.xml which contains a mms address, followed by a list of available video files. So with that in-mind, I just took the mms address + a video file, and put that address into VLC media player.

This method worked, but it was not reliable. Sometimes it would work, but most of the times VLC would complain about not being able to find the file. When it did work though, it would work without issue for a few hours. This also led me to create a playlist, and in this playlist, I queued up an entire day’s worth of video. Was relatively easy to do since the video files all follow a certain format (TBS01_20141022_1800.asf = TBS01 (channel) + YYYY-MM-DD + Hour). If I recall correctly, this allowed for seamless playback of media from NTKTV’s server. This method of streaming got more unreliable as time went on, and I eventually just gave up on it, and continued to use the .jar file on Windows for some time.

I decided to check a forum thread about methods for streaming Japanese TV again a little bit ago, and saw that someone mentioned they had gotten NTKTV working on OS X (but they didn’t bother to post how). I replied to another post about why it didn’t work on Linux, and an idea hit me.

The way NTKTV works is, it downloads a small chunk of the video from the server to the OS’s temp folder, opens up Windows Media Player, and then continues to download the rest of the video in the background, while WMP plays it back. The issue on Linux however was that the video refused to start downloading at all.

When starting the .jar file in Terminal, I noticed a os_temp: line (which I somehow missed months ago). This line by-default led to /tmp/. My user account however does not have RW access to this folder, and I imagine this is the reason why the .jar couldn’t initiate the download. So the idea here was to change where Java should throw temporary files.

With a little bit of searching, I came across this page, which mentioned the command java -Djava.io.tmpdir=/path/to/tmpdir. I simply added that to the command I was using, and lo and behold, NTKTV’s app downloaded files just fine.

Playback is fine with mpv 🙂

My next objective is to figure out how to get my Chromecast involved. Was easy in Windows; just relied on VLC’s browser plugin, casted the tab, and threw the .asf into Chrome. Now that NPAPI plugin support is gone from Chrome in Linux however, the plugin no longer works.

Edit: Videostream seems to do a great job. It can also handle video files that are still downloading in the background too.

And for anyone curious, the full command I use to set the tmp directory and launch the .jar file is: java -Djava.io.tmpdir=/home/espionage724/tmp -jar ‘/home/espionage724/Videos/ntktv/Kantofixed/TBS.jar’

Story of my Gateway VX1120 and Custom Refresh Rates on Windows and Linux

A few months ago I picked up a Gateway VX1120 from a computer store in town for $5, not knowing if it would work or not. I was always a fan of CRT monitors, and seeing something of this size, I had to jump on it.

Got it home, plugged it in, and found out that it worked fine. Instantly replaced the Acer S201HL I was using without regrets. Colors were more vibrant, and animations are much smoother (one of my favorite things to do when switching from LCD to CRT is to move a window across my desktop to observe the smoothness). Plus the resolutions available were extensive, so I was sure I could find the right resolution to use daily. The other CRT monitors I have in the house were limited to around 1024×768, or something slightly higher at a lower refresh rate, so they weren’t too ideal.

After some time, I found that the resolution of 1280×960 suited perfectly as a default resolution. It’s not high enough to make text hard to see, and at the same time, it’s large enough for the desktop not to feel cramped. The highest stock refresh rate for this resolution was 85Hz, which was great and all, but I soon looked into a way to improve that.

On Windows, I used a tool called Custom Resolution Utility (CRU). It allowed me to generate custom resolutions and refresh rates. I wanted to run at 120Hz just to be able to claim I had such a monitor, so that was the first refresh rate I tried. It didn’t work; and the monitor complained about the frequency being out-of-range.

After a little bit of research, I found that my horizontal scan frequency could go as high as 121kHz. So going by that, I then had the idea to keep trying resolutions with CRU until my horizontal scan frequency was just under that limit. Lucky me, 119Hz seemed to have worked fine.

So in Windows, the refresh rate wasn’t too hard to handle. Things got a bit more interesting when I went over to Linux however. I use an AMD Radeon HD 7850 graphics card (this specifically), so I have the choice of either using AMD’s proprietary driver (fglrx), or the open-source drivers. The refresh rate on my screen however seems to act differently depending on which driver I use though.

If I recall correctly, I was able to use the CVT-generated 119Hz with fglrx without issue (it’s been a while since I used fglrx with this monitor), but this wasn’t the case with the open-source driver.

Looking back at cvt, I noticed that my hsync value was 122.59 for 119Hz. Definitely over the 121kHZ limit, so then I tried going to 118Hz. It ended up at 121.45, which was still over the limit. I wasn’t sure if 121kHZ was a hard limit, so I added the refresh rate and tried it anyway. Both 119Hz and 118Hz failed to work; so I tried 117Hz. Got the hsync value of 120.31, which was safely under the limit, and worked fine.

I’m unsure how CRU and cvt generate the numbers they do, but a comparison at some point would be a great idea, whenever I find the time to do so.

So far, this monitor is still working great, and I have no plans of replacing it anytime soon, unless I go back to my standing desk setup.